Main Page

<mediawiki xmlns="http://www.mediawiki.org/xml/export-0.11/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mediawiki.org/xml/export-0.11/ http://www.mediawiki.org/xml/export-0.11.xsd" version="0.11" xml:lang="en">
  <siteinfo>
    <sitename>FixForwarding</sitename>
    <dbname>FFdb</dbname>
    <base>http://fixforwarding.org/wiki/Main_Page</base>
    <generator>MediaWiki 1.39.10</generator>
    <case>case-sensitive</case>
    <namespaces>
      <namespace key="-2" case="case-sensitive">Media</namespace>
      <namespace key="-1" case="first-letter">Special</namespace>
      <namespace key="0" case="case-sensitive" />
      <namespace key="1" case="case-sensitive">Talk</namespace>
      <namespace key="2" case="first-letter">User</namespace>
      <namespace key="3" case="first-letter">User talk</namespace>
      <namespace key="4" case="case-sensitive">FixForwarding</namespace>
      <namespace key="5" case="case-sensitive">FixForwarding talk</namespace>
      <namespace key="6" case="case-sensitive">File</namespace>
      <namespace key="7" case="case-sensitive">File talk</namespace>
      <namespace key="8" case="first-letter">MediaWiki</namespace>
      <namespace key="9" case="first-letter">MediaWiki talk</namespace>
      <namespace key="10" case="case-sensitive">Template</namespace>
      <namespace key="11" case="case-sensitive">Template talk</namespace>
      <namespace key="12" case="case-sensitive">Help</namespace>
      <namespace key="13" case="case-sensitive">Help talk</namespace>
      <namespace key="14" case="case-sensitive">Category</namespace>
      <namespace key="15" case="case-sensitive">Category talk</namespace>
    </namespaces>
  </siteinfo>
<page arvcontinue="">
  <title>Main Page</title>
  <ns>0</ns>
  <id>1</id>
  <revision>
    <id>1</id>
    <timestamp>2008-02-25T19:34:38Z</timestamp>
    <contributor>
      <username>MediaWiki default</username>
      <id>0</id>
    </contributor>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="444" xml:space="preserve">&lt;big&gt;'''MediaWiki has been successfully installed.'''&lt;/big&gt;

Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

== Getting started ==

* [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list]
* [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ]
* [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]</text>
    <sha1>928e1deea259c70afc3513c66f29f3fcd740d8bf</sha1>
  </revision>
  <revision>
    <id>1405</id>
    <parentid>1</parentid>
    <timestamp>2008-02-25T19:39:14Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Getting started */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="464" xml:space="preserve">&lt;big&gt;'''MediaWiki has been successfully installed.'''&lt;/big&gt;

Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

== Getting started ==
Apparently works...

* [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list]
* [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ]
* [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]</text>
    <sha1>d7f3d08516d601587ef6ce41ee1518d880be3072</sha1>
  </revision>
  <revision>
    <id>1406</id>
    <parentid>1405</parentid>
    <timestamp>2008-09-06T13:02:10Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Initial text</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="1572" xml:space="preserve">&lt;big&gt;'''Once upon a time SMTP was a simple protocol...'''&lt;/big&gt;

Forwarding is a generally used but not thoroughly considered feature of Internet email architecture. Admins and power users have the ability to unilaterally add ''forwarding recipes'' onto a server, so that email messages destined to a given mailbox are forwarded or exploded to the recipients thus configured.

In the horrid mess that is Internet Email nowadays, a jungle where illegal spam messages largely outweigh legitimate ones, forwarding stands out as a prominent problem. Let's fix it.

== The problem ==
Savage forwarding produces quite some shortcomings:
* Recipients have no means to directly control the forwarding mechanism.
* Responsibility for injecting spam becomes ambiguous.
* Bounces may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

== The solution: Standardize forwarding practices ==
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. It must be designed so as to reflect this property; in particular, there must be a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

Just think about guidelines and laws that talk about the much discussed ''opt-in'' and ''opt-out'' methods for delivering commercial newsletters, and consider how could such kind of rules be possibly enforced in the absence of any standard record telling if and when someone actually ''did'' opt in or out. Are we serious about using email?</text>
    <sha1>c98e6dbc264cc9d1901fbf67c9b2fb12e1c7de46</sha1>
  </revision>
  <revision>
    <id>1420</id>
    <parentid>1406</parentid>
    <timestamp>2008-11-03T15:49:43Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>add links</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="1580" xml:space="preserve">&lt;big&gt;'''Once upon a time SMTP was a simple protocol...'''&lt;/big&gt;

[[Forwarding]] is a generally used but not thoroughly considered feature of Internet email architecture. Admins and power users have the ability to unilaterally add ''[[forwarding recipe]]s'' onto a server, so that email messages destined to a given mailbox are forwarded or exploded to the recipients thus configured.

In the horrid mess that is Internet Email nowadays, a jungle where illegal spam messages largely outweigh legitimate ones, forwarding stands out as a prominent problem. Let's fix it.

== The problem ==
Savage forwarding produces quite some shortcomings:
* Recipients have no means to directly control the forwarding mechanism.
* Responsibility for injecting spam becomes ambiguous.
* Bounces may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

== The solution: Standardize forwarding practices ==
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. It must be designed so as to reflect this property; in particular, there must be a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

Just think about guidelines and laws that talk about the much discussed ''opt-in'' and ''opt-out'' methods for delivering commercial newsletters, and consider how could such kind of rules be possibly enforced in the absence of any standard record telling if and when someone actually ''did'' opt in or out. Are we serious about using email?</text>
    <sha1>7acdd6e6150a25081628bcf8b7a76e1b96914713</sha1>
  </revision>
  <revision>
    <id>1443</id>
    <parentid>1420</parentid>
    <timestamp>2008-12-05T11:05:35Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* The solution: Standardize forwarding practices */ link to the solution proposed</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="1600" xml:space="preserve">&lt;big&gt;'''Once upon a time SMTP was a simple protocol...'''&lt;/big&gt;

[[Forwarding]] is a generally used but not thoroughly considered feature of Internet email architecture. Admins and power users have the ability to unilaterally add ''[[forwarding recipe]]s'' onto a server, so that email messages destined to a given mailbox are forwarded or exploded to the recipients thus configured.

In the horrid mess that is Internet Email nowadays, a jungle where illegal spam messages largely outweigh legitimate ones, forwarding stands out as a prominent problem. Let's fix it.

== The problem ==
Savage forwarding produces quite some shortcomings:
* Recipients have no means to directly control the forwarding mechanism.
* Responsibility for injecting spam becomes ambiguous.
* Bounces may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

== The solution: Standardize forwarding practices ==
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

Just think about guidelines and laws that talk about the much discussed ''opt-in'' and ''opt-out'' methods for delivering commercial newsletters, and consider how could such kind of rules be possibly enforced in the absence of any standard record telling if and when someone actually ''did'' opt in or out. Are we serious about using email?</text>
    <sha1>c124e6bdc58af0952079e93f78487c4ced9fed57</sha1>
  </revision>
</page>
<page arvcontinue="">
  <title>FixForwarding:Copyrights</title>
  <ns>4</ns>
  <id>2</id>
  <revision>
    <id>1407</id>
    <timestamp>2008-09-07T18:00:08Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>scratch text</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="53" xml:space="preserve">FixForwarding.org content is available under GFDLv1.2</text>
    <sha1>636cd69ecf6ffc47d7c59876c46e8a5161b2aa8c</sha1>
  </revision>
  <revision>
    <id>1409</id>
    <parentid>1407</parentid>
    <timestamp>2008-09-08T08:04:51Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>expanded</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="744" xml:space="preserve">The content of this site is copyright of FixForwarding.org and is available as stated below. This means that each contributing author agrees to submit content using those terms. In this respect, FixForwarding.org is an abstract entity that stands for the set of Authors that contributed to the resulting "joint work".

Permission is granted to copy, distribute and/or modify the contents of this site under the terms of the [http://www.gnu.org/licenses/fdl-1.2.html#TOC1 GNU Free Documentation License, Version 1.2] or any later version published by the [http://www.fsf.org/ Free Software Foundation]; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.  A copy of the license can be following the links in this paragraph.</text>
    <sha1>01dd03e1e26f671001a6633521011388b5b10807</sha1>
  </revision>
  <revision>
    <id>1410</id>
    <parentid>1409</parentid>
    <timestamp>2008-09-08T11:57:49Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>wording</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="741" xml:space="preserve">The content of this site is copyright of FixForwarding.org, and is available as stated below. This means that Authors agree to submit their contribution using such terms. In this respect, FixForwarding.org is an abstract entity that stands for the set of Authors who have contributed to the resulting "joint work".

Permission is granted to copy, distribute and/or modify the contents of this site under the terms of the [http://www.gnu.org/licenses/fdl-1.2.html#TOC1 GNU Free Documentation License, Version 1.2] or any later version published by the [http://www.fsf.org/ Free Software Foundation]; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.  A copy of the license can be following the links in this paragraph.</text>
    <sha1>323e9ed6fa6c2d2e94906d66eefcc0bb5c4169e4</sha1>
  </revision>
</page>
<page arvcontinue="">
  <title>Help:Editing</title>
  <ns>12</ns>
  <id>4</id>
  <revision>
    <id>1411</id>
    <timestamp>2008-09-08T13:58:15Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Initial text</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="331" xml:space="preserve">FixForwarding uses [http://www.mediawiki.org/ MediaWiki] software. However, that software currently ships with the ''Help'' section in a blank state. Please consult the corresponding sections present in full blown projects using the same software. In particular, [[wp:Wikipedia:How to edit a page]] and [[wp:Wikipedia:Cheatsheet]].</text>
    <sha1>061e3e2f44a67a808842332cf0f930595be1eab3</sha1>
  </revision>
  <revision>
    <id>1412</id>
    <parentid>1411</parentid>
    <timestamp>2008-09-08T13:59:10Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="337" xml:space="preserve">FixForwarding uses [http://www.mediawiki.org/ MediaWiki] software. However, that software currently ships with the ''Help'' section in a blank state. Please consult the corresponding sections present in full blown projects using this same wiki software. In particular, [[wp:Wikipedia:How to edit a page]] and [[wp:Wikipedia:Cheatsheet]].</text>
    <sha1>6970cf68ba1deb72c2bf3d6155db230bc6589dae</sha1>
  </revision>
</page>
<page arvcontinue="">
  <title>FixForwarding:About</title>
  <ns>4</ns>
  <id>5</id>
  <revision>
    <id>1413</id>
    <timestamp>2008-09-08T14:06:40Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Initial text</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="228" xml:space="preserve">FixForwarding.org is a web site dedicated to stating the problem of Email forwarding, devising possible solutions and possibly implementing them using publicly available server software. That is, to standardize email forwarding.</text>
    <sha1>dbda2ae8dabe3cfb658c689f9cc6712158cae255</sha1>
  </revision>
</page>
<page arvcontinue="">
  <title>FixForwarding:Privacy policy</title>
  <ns>4</ns>
  <id>6</id>
  <revision>
    <id>1414</id>
    <timestamp>2008-09-08T14:26:14Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Initial text</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="940" xml:space="preserve">== Visitors ==
Simply visiting the web site does not expose your identity publicly. However, regular access logs remain on the server for the prescribed amount of time. The logs may contain the IP address you used, your browser's name, version, language setting, and possibly the referral URL.

== Authors ==
When you edit any page in the wiki, you are publishing a document. This is a public act, and you are identified publicly with that edit as its author. Any content that you contribute will be made available under the GNU Free Documentation License (see [[FixForwarding:Copyrights]]).

You are required to log in before you can publish in the wiki.

If you are logged in, you will be identified by your user name. This may be your real name if you so choose, or you may choose to publish under a pseudonym, whatever user name you selected when you created your account.

Account creation currently requires a confirmed email address.</text>
    <sha1>1a80c692860bf23ea5e55dbe805d6f37a7e97409</sha1>
  </revision>
  <revision>
    <id>1417</id>
    <parentid>1414</parentid>
    <timestamp>2008-09-08T17:26:53Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Added privacy clause and topics subsection</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2296" xml:space="preserve">Personally identifiable data is submitted to this site according to the [http://www.cdt.org/privacy/eudirective/EU_Directive_.html European directives on the protection of individuals with regard to the processing of personal data]. In that respect, data is processed locally on a secured server and will not be made available to third parties except in case of ''i)'' explicit request of the data subject, or ''ii)'' compulsory request from law enforcement.

The controller as well as the responsible for the data processing is the webmaster[[Image:at_sign.png|14px|bottom| at]]fixforwarding.org, who can be identified via the public ''whois'' database and can be contacted at the given email address.

== Visitors ==
Simply visiting the web site does not expose your identity publicly. However, regular access logs remain on the server for the prescribed amount of time. The logs may contain the IP address you used, your browser's name, version, language setting, and possibly the referral URL.

== Authors ==
When you edit any page in the wiki, you are publishing a document. This is a public act, and you are identified publicly with that edit as its author. Any content that you contribute will be made available under the GNU Free Documentation License (see [[FixForwarding:Copyrights]]).

You are required to log in before you can publish in the wiki.

If you are logged in, you will be identified by your user name. This may be your real name if you so choose, or you may choose to publish under a pseudonym, whatever user name you selected when you created your account.

Account creation currently requires a confirmed email address. It is not published nor disclosed except as mentioned above.

== Topics ==
This site is devoted to the standardization of email forwarding. As email is a basic mean of human communication, almost any topic may possibly fit into the discussion. In particular, non-technical arguments pertinent to communication in general are welcome. However, this is not a generic blog nor an encyclopedia, and a precise relevance is required.

Non-pertinent contributions will be deleted. In addition, the webmaster reserves the right to eradicate from the site any morally offensive or otherwise illegal material, as well as the account(s) where it originated from.</text>
    <sha1>7e81c82caec2418640886267743fa234143a54fd</sha1>
  </revision>
</page>
<page arvcontinue="">
  <title>FixForwarding:General disclaimer</title>
  <ns>4</ns>
  <id>7</id>
  <revision>
    <id>1415</id>
    <timestamp>2008-09-08T14:50:42Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Initial text</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="1457" xml:space="preserve">The content of this site is being provided freely, and no kind of agreement or contract is created between you and the owners or users of this site, the owners of the servers upon which it is housed, individual contributors to these pages, or project administrators, sysops or anyone else connected with this project subject to your claims against them directly. You are granted a limited license to copy anything from this site; it does not create or imply any liability whatsoever on the part of FixForwarding.org in the person of any of its authors, agents, organizers or other users.

Any of the trademarks, service marks, collective marks, design rights, personality rights or similar rights that are mentioned, used or cited on this site are the property of their respective owners. Unless otherwise stated, FixForwarding.org is neither endorsed by nor affiliated with any of the holders of such rights, nor can it grant rights to use otherwise protected materials. ''Your use of any such incorporeal property is at your own risk.''

Although this site prohibits the submission of copyrighted work without permission, it cannot be responsible for any specific violation that may gatecrash unnoticed. Likewise, since this site is dedicated to the discussion of technical and social problems in Internet Email, it does not want to host any morally offensive content; however, it cannot guarantee that intruders will not be able to circumvent its policy.</text>
    <sha1>9affde7346795c8b01456f8fa6178d9acae5f6b9</sha1>
  </revision>
</page>
<page arvcontinue="">
  <title>File:at sign.png</title>
  <ns>6</ns>
  <id>8</id>
  <revision>
    <id>1416</id>
    <timestamp>2008-09-08T17:17:45Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>the strudel, copied from MediaWiki's svg 14px thumb</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="51" xml:space="preserve">the strudel, copied from MediaWiki's svg 14px thumb</text>
    <sha1>1b09465815cd1f28a801922484d4e03cd255ebbd</sha1>
  </revision>
</page>
<page arvcontinue="">
  <title>Forwarding</title>
  <ns>0</ns>
  <id>9</id>
  <revision>
    <id>1418</id>
    <timestamp>2008-11-03T12:47:21Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Definition of forwarding</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2965" xml:space="preserve">Mail '''forwarding''' is the act of transferring a message from the server where the message recently arrived to another server that is deemed nearer to the intended recipient(s).

== Meaning of the term in this site ==

We focus on two types of message transferring that servers do automatically upon receiving a message: possibly altering the envelope or leaving it intact.

=== Forwarding with a new envelope ===
The receiving server finds a [[forwarding recipe]] corresponding to one of the message's recipient addresses, and it honors it by
* replacing the recipient address with the ones listed in the recipe, and
* replacing the ''sender address'', according to the recipe's policy.

The server address defines the behavior of the email system in the case of delivery failures: Even if the next server will accept the forwarded message, a delivery failure may occur further downstream. In that case, a failure notice should be delivered to the mailbox defined by setting the sender address at this stage. Therefore, there are a few considerations that may affect the policy:
# Should the forwarding recipe be modified as a consequence of delivery failures?
# Should the replaced recipient addresses be made known to the upstream sender?
 
This action is described in section 3.9.2 of &lt;nowiki&gt;RFC 5321&lt;/nowiki&gt;, ''List''. Note that the preceding section 3.9.1 of that RFC, ''Alias'', describes a forwarding method useful for ''intra-domain'' forwarding. See below.

=== Forwarding with the same envelope===
This is the operation that a ''backup MX'' accomplishes to deliver messages to primary MXes of the given domain, where further processing may occur. It may happen that a relay, e.g. the author's outgoing mail server, cannot reach a primary MX for a given recipient. That may occur if the target server is temporarily unreachable. Thus, secondary MXes can cope with network outages.

== Other acceptations of ''forwarding'' ==

That term is commonly used for the manual operation initiated by users by clicking on the ''Forward'' button of their MUAs. From the SMTP point of view, that action is not a forwarding, in the sense that the new message will have a new envelope, a new Message-ID, and a possibly altered content.

In addition, '''alias expansion''' is often referred by this term. The main difference between forwarding and alias expansion, according to SMTP, is that the latter does not alter the envelope sender. If the operation is carried out on the same server, it may not undergo a new SMTP transaction, and just write the message to a different location on disc. However, it is still quite common for servers to forward messages badly omitting to properly set a new envelope sender: while technically resembling an alias expansion, ''ill forwarding'' breaks protocols that depend on the envelope sender, e.g. [http://www.openspf.org/ SPF].

== See also ==
* [[wp:Email forwarding]]
* RFC 5321 Simple Mail Transfer Protocol, section 3.9</text>
    <sha1>5dbc3c6aee34bbd659f05e919f74d0b235b3387e</sha1>
  </revision>
  <revision>
    <id>1421</id>
    <parentid>1418</parentid>
    <timestamp>2008-11-22T11:33:25Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Forwarding agreement solution */ new section</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="3711" xml:space="preserve">Mail '''forwarding''' is the act of transferring a message from the server where the message recently arrived to another server that is deemed nearer to the intended recipient(s).

== Meaning of the term in this site ==

We focus on two types of message transferring that servers do automatically upon receiving a message: possibly altering the envelope or leaving it intact.

=== Forwarding with a new envelope ===
The receiving server finds a [[forwarding recipe]] corresponding to one of the message's recipient addresses, and it honors it by
* replacing the recipient address with the ones listed in the recipe, and
* replacing the ''sender address'', according to the recipe's policy.

The server address defines the behavior of the email system in the case of delivery failures: Even if the next server will accept the forwarded message, a delivery failure may occur further downstream. In that case, a failure notice should be delivered to the mailbox defined by setting the sender address at this stage. Therefore, there are a few considerations that may affect the policy:
# Should the forwarding recipe be modified as a consequence of delivery failures?
# Should the replaced recipient addresses be made known to the upstream sender?
 
This action is described in section 3.9.2 of &lt;nowiki&gt;RFC 5321&lt;/nowiki&gt;, ''List''. Note that the preceding section 3.9.1 of that RFC, ''Alias'', describes a forwarding method useful for ''intra-domain'' forwarding. See below.

=== Forwarding with the same envelope===
This is the operation that a ''backup MX'' accomplishes to deliver messages to primary MXes of the given domain, where further processing may occur. It may happen that a relay, e.g. the author's outgoing mail server, cannot reach a primary MX for a given recipient. That may occur if the target server is temporarily unreachable. Thus, secondary MXes can cope with network outages.

== Forwarding agreement solution ==
&lt;!-- TODO: add template {{main|Forwarding agreement}} --&gt;
''Main article: [[Forwarding agreement]]''

An MX server who accepts such specific form of agreement should advertise it during the SMTP handshake. A forwarder may then choose to come into an agreement, or just submit mail without worrying about reputation and deliverability. Concluding the agreement requires a policy match involving the forwarder and the recipient. End users set their policies specifying relevant options at the target MX, or just accepting the default.

After the agreement has been set up, the forwarder is supplied with a valid user id and password which are only valid for forwarding that kind of mail to the given recipient.

== Other acceptations of ''forwarding'' ==

That term is commonly used for the manual operation initiated by users by clicking on the ''Forward'' button of their MUAs. From the SMTP point of view, that action is not a forwarding, in the sense that the new message will have a new envelope, a new Message-ID, and a possibly altered content.

In addition, '''alias expansion''' is often referred by this term. The main difference between forwarding and alias expansion, according to SMTP, is that the latter does not alter the envelope sender. If the operation is carried out on the same server, it may not undergo a new SMTP transaction, and just write the message to a different location on disc. However, it is still quite common for servers to forward messages badly omitting to properly set a new envelope sender: while technically resembling an alias expansion, ''ill forwarding'' breaks protocols that depend on the envelope sender, e.g. [http://www.openspf.org/ SPF].

== See also ==
* [[wp:Email forwarding]]
* RFC 5321 Simple Mail Transfer Protocol, section 3.9</text>
    <sha1>3fd6d6564fed6b2a0b47481f5f42c13f66b0a6e6</sha1>
  </revision>
  <revision>
    <id>1422</id>
    <parentid>1421</parentid>
    <timestamp>2008-11-22T11:42:26Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Forwarding agreement solution */ spell forwarding lowcase</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="3711" xml:space="preserve">Mail '''forwarding''' is the act of transferring a message from the server where the message recently arrived to another server that is deemed nearer to the intended recipient(s).

== Meaning of the term in this site ==

We focus on two types of message transferring that servers do automatically upon receiving a message: possibly altering the envelope or leaving it intact.

=== Forwarding with a new envelope ===
The receiving server finds a [[forwarding recipe]] corresponding to one of the message's recipient addresses, and it honors it by
* replacing the recipient address with the ones listed in the recipe, and
* replacing the ''sender address'', according to the recipe's policy.

The server address defines the behavior of the email system in the case of delivery failures: Even if the next server will accept the forwarded message, a delivery failure may occur further downstream. In that case, a failure notice should be delivered to the mailbox defined by setting the sender address at this stage. Therefore, there are a few considerations that may affect the policy:
# Should the forwarding recipe be modified as a consequence of delivery failures?
# Should the replaced recipient addresses be made known to the upstream sender?
 
This action is described in section 3.9.2 of &lt;nowiki&gt;RFC 5321&lt;/nowiki&gt;, ''List''. Note that the preceding section 3.9.1 of that RFC, ''Alias'', describes a forwarding method useful for ''intra-domain'' forwarding. See below.

=== Forwarding with the same envelope===
This is the operation that a ''backup MX'' accomplishes to deliver messages to primary MXes of the given domain, where further processing may occur. It may happen that a relay, e.g. the author's outgoing mail server, cannot reach a primary MX for a given recipient. That may occur if the target server is temporarily unreachable. Thus, secondary MXes can cope with network outages.

== Forwarding agreement solution ==
&lt;!-- TODO: add template {{main|Forwarding agreement}} --&gt;
''Main article: [[forwarding agreement]]''

An MX server who accepts such specific form of agreement should advertise it during the SMTP handshake. A forwarder may then choose to come into an agreement, or just submit mail without worrying about reputation and deliverability. Concluding the agreement requires a policy match involving the forwarder and the recipient. End users set their policies specifying relevant options at the target MX, or just accepting the default.

After the agreement has been set up, the forwarder is supplied with a valid user id and password which are only valid for forwarding that kind of mail to the given recipient.

== Other acceptations of ''forwarding'' ==

That term is commonly used for the manual operation initiated by users by clicking on the ''Forward'' button of their MUAs. From the SMTP point of view, that action is not a forwarding, in the sense that the new message will have a new envelope, a new Message-ID, and a possibly altered content.

In addition, '''alias expansion''' is often referred by this term. The main difference between forwarding and alias expansion, according to SMTP, is that the latter does not alter the envelope sender. If the operation is carried out on the same server, it may not undergo a new SMTP transaction, and just write the message to a different location on disc. However, it is still quite common for servers to forward messages badly omitting to properly set a new envelope sender: while technically resembling an alias expansion, ''ill forwarding'' breaks protocols that depend on the envelope sender, e.g. [http://www.openspf.org/ SPF].

== See also ==
* [[wp:Email forwarding]]
* RFC 5321 Simple Mail Transfer Protocol, section 3.9</text>
    <sha1>148686d75c6666790796758d7625ef82bd0b35df</sha1>
  </revision>
</page>
<page arvcontinue="">
  <title>forwarding recipe</title>
  <ns>0</ns>
  <id>10</id>
  <revision>
    <id>1419</id>
    <timestamp>2008-11-03T15:47:20Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Definition of forwarding recipe</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="3348" xml:space="preserve">A '''forwarding recipe''' is the procedural data by which a mail server can build a new envelope for an existing message before re-injecting it into the mail system. It includes the forwarded address that the original message bore, one or more new recipient addresses to whom the re-injected message is destined, and a policy. The policy determines the new envelope sender address, at least.

== Common forwarding recipes ==
Historically, recipes were written in [http://www.sendmail.org/ sendmail]'s &lt;code&gt;.forward&lt;/code&gt; files in a recipient's home directory, in order to elicit specific forwarding behavior from the server when a message is received at a given mailbox. Recipes have to be addressable by their forwarded address, so that the software can find any relevant recipe upon message reception. Obviously, the software that implements the SMTP server dictates the format that recipes have to comply. Depending on the implementation, the data that conceptually makes up a recipe may be spread among several files.

A pipe character (&lt;code&gt;|&lt;/code&gt;) in a &lt;code&gt;.forward&lt;/code&gt; file allows executing external programs. Similar concepts work for [http://www.qmail.org/man/man5/dot-qmail.html .qmail] and [http://www.courier-mta.org/dot-courier.html .courier]. A forwarding recipe may consist of
&lt;pre&gt;
| sendmail -f postmaster@example.org newrecipient@example.com
&lt;/pre&gt;
Notice that the forwarded address is implied by the location on disc where the recipe is written. In addition, the behavior triggered by messages bouncing to &lt;code&gt;postmaster@example.org&lt;/code&gt; is conceptually part of this recipe but is specified somewhere else.

Courier-MTA comes with a delivery agent, [http://www.courier-mta.org/maildrop.html maildrop], that implements a local filtering engine with its own programming language. It allows to implement forwarding recipes that are configurable at different levels; that is, more easily maintainable.

== Policy considerations ==
In its simplest form, a forwarding recipe may be difficult to manage. The complexity may increase depending on who and how can create mailboxes and recipes on the system, what spam filtering options are available, and spam reporting mechanisms.

On a small system where only the postmaster creates mailboxes and recipes, for example, a recipe as exemplified above may make sense. Upon receiving a delivery failure, the postmaster should decide whether to drop the recipe as the target address becomes unavailable or to advise the final recipient that the relevant mailbox is full. Larger systems will require to automate that behavior, therefore it becomes necessary to define exactly when and how each operation is performed. For example, a policy can specify a different behavior for a mailbox full situation if an alternative email address or, say, an SMS-enabled phone number are available for advising the final recipient.

A policy may contain various configuration items. It can provide for a number of different states, so that the server can stop receiving new mail in certain cases, possibly requiring that appropriate local responses are given, e.g.:
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;, or 
251  User not local; will forward to &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

A forwarding recipe's policy is limited to local behavior. It is not a ''forwarding agreement''.</text>
    <sha1>78854f1ac831a9e90c84526617a8033cb20d5c73</sha1>
  </revision>
  <revision>
    <id>1425</id>
    <parentid>1419</parentid>
    <timestamp>2008-11-29T11:54:03Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Quest for agreement */ new section</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4008" xml:space="preserve">A '''forwarding recipe''' is the procedural data by which a mail server can build a new envelope for an existing message before re-injecting it into the mail system. It includes the forwarded address that the original message bore, one or more new recipient addresses to whom the re-injected message is destined, and a policy. The policy determines the new envelope sender address, at least.

== Common forwarding recipes ==
Historically, recipes were written in [http://www.sendmail.org/ sendmail]'s &lt;code&gt;.forward&lt;/code&gt; files in a recipient's home directory, in order to elicit specific forwarding behavior from the server when a message is received at a given mailbox. Recipes have to be addressable by their forwarded address, so that the software can find any relevant recipe upon message reception. Obviously, the software that implements the SMTP server dictates the format that recipes have to comply. Depending on the implementation, the data that conceptually makes up a recipe may be spread among several files.

A pipe character (&lt;code&gt;|&lt;/code&gt;) in a &lt;code&gt;.forward&lt;/code&gt; file allows executing external programs. Similar concepts work for [http://www.qmail.org/man/man5/dot-qmail.html .qmail] and [http://www.courier-mta.org/dot-courier.html .courier]. A forwarding recipe may consist of
&lt;pre&gt;
| sendmail -f postmaster@example.org newrecipient@example.com
&lt;/pre&gt;
Notice that the forwarded address is implied by the location on disc where the recipe is written. In addition, the behavior triggered by messages bouncing to &lt;code&gt;postmaster@example.org&lt;/code&gt; is conceptually part of this recipe but is specified somewhere else.

Courier-MTA comes with a delivery agent, [http://www.courier-mta.org/maildrop.html maildrop], that implements a local filtering engine with its own programming language. It allows to implement forwarding recipes that are configurable at different levels; that is, more easily maintainable.

== Quest for agreement ==
A forwarding recipe introduces a new segment in the message path, which should be considered within the recipient's realm. In fact, the ''newrecipient'' address is [[wp:personally identifiable information]] of its owner, therefore its owner should have explicitly given a permission to use it in a certain way. That permission, also called ''opt-in'', is not routinely asked for. Even when it is, e.g. when subscribing to a mailing list, the relevant forwarding recipe is stored at the forwarding host only. [[Forwarding agreement]]s are proposed to obviate this limitation and let a forwarding recipe be known and acted upon by its owner, directly from the target host.

== Policy considerations ==
In its simplest form, a forwarding recipe may be difficult to manage. The complexity may increase depending on who and how can create mailboxes and recipes on the system, what spam filtering options are available, and spam reporting mechanisms.

On a small system where only the postmaster creates mailboxes and recipes, for example, a recipe as exemplified above may make sense. Upon receiving a delivery failure, the postmaster should decide whether to drop the recipe as the target address becomes unavailable or to advise the final recipient that the relevant mailbox is full. Larger systems will require to automate that behavior, therefore it becomes necessary to define exactly when and how each operation is performed. For example, a policy can specify a different behavior for a mailbox full situation if an alternative email address or, say, an SMS-enabled phone number are available for advising the final recipient.

A policy may contain various configuration items. It can provide for a number of different states, so that the server can stop receiving new mail in certain cases, possibly requiring that appropriate local responses are given, e.g.:
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;, or 
251  User not local; will forward to &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

A forwarding recipe's policy is limited to local behavior.</text>
    <sha1>d9b439063ccdbf58dd9b1ab6f96eb47c9b0ef438</sha1>
  </revision>
  <revision>
    <id>1426</id>
    <parentid>1425</parentid>
    <timestamp>2008-11-29T12:04:32Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Policy considerations */ mention that states include nondisclosure flag</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4144" xml:space="preserve">A '''forwarding recipe''' is the procedural data by which a mail server can build a new envelope for an existing message before re-injecting it into the mail system. It includes the forwarded address that the original message bore, one or more new recipient addresses to whom the re-injected message is destined, and a policy. The policy determines the new envelope sender address, at least.

== Common forwarding recipes ==
Historically, recipes were written in [http://www.sendmail.org/ sendmail]'s &lt;code&gt;.forward&lt;/code&gt; files in a recipient's home directory, in order to elicit specific forwarding behavior from the server when a message is received at a given mailbox. Recipes have to be addressable by their forwarded address, so that the software can find any relevant recipe upon message reception. Obviously, the software that implements the SMTP server dictates the format that recipes have to comply. Depending on the implementation, the data that conceptually makes up a recipe may be spread among several files.

A pipe character (&lt;code&gt;|&lt;/code&gt;) in a &lt;code&gt;.forward&lt;/code&gt; file allows executing external programs. Similar concepts work for [http://www.qmail.org/man/man5/dot-qmail.html .qmail] and [http://www.courier-mta.org/dot-courier.html .courier]. A forwarding recipe may consist of
&lt;pre&gt;
| sendmail -f postmaster@example.org newrecipient@example.com
&lt;/pre&gt;
Notice that the forwarded address is implied by the location on disc where the recipe is written. In addition, the behavior triggered by messages bouncing to &lt;code&gt;postmaster@example.org&lt;/code&gt; is conceptually part of this recipe but is specified somewhere else.

Courier-MTA comes with a delivery agent, [http://www.courier-mta.org/maildrop.html maildrop], that implements a local filtering engine with its own programming language. It allows to implement forwarding recipes that are configurable at different levels; that is, more easily maintainable.

== Quest for agreement ==
A forwarding recipe introduces a new segment in the message path, which should be considered within the recipient's realm. In fact, the ''newrecipient'' address is [[wp:personally identifiable information]] of its owner, therefore its owner should have explicitly given a permission to use it in a certain way. That permission, also called ''opt-in'', is not routinely asked for. Even when it is, e.g. when subscribing to a mailing list, the relevant forwarding recipe is stored at the forwarding host only. [[Forwarding agreement]]s are proposed to obviate this limitation and let a forwarding recipe be known and acted upon by its owner, directly from the target host.

== Policy considerations ==
In its simplest form, a forwarding recipe may be difficult to manage. The complexity may increase depending on who and how can create mailboxes and recipes on the system, what spam filtering options are available, and spam reporting mechanisms.

On a small system where only the postmaster creates mailboxes and recipes, for example, a recipe as exemplified above may make sense. Upon receiving a delivery failure, the postmaster should decide whether to drop the recipe as the target address becomes unavailable or to advise the final recipient that the relevant mailbox is full. Larger systems will require to automate that behavior, therefore it becomes necessary to define exactly when and how each operation is performed. For example, a policy can specify a different behavior for a mailbox full situation if an alternative email address or, say, an SMS-enabled phone number are available for advising the final recipient.

A policy may contain various configuration items. It can provide for a number of different states, so that the server can stop receiving new mail in certain cases, possibly requiring that appropriate local responses are given, e.g.:
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;, or 
251  User not local; will forward to &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

Two flags are as follows:
* '''enabled''' store and forward may work, and
* '''non-disclosure''' the target address should never leak.

A forwarding recipe's policy is limited to local behavior.</text>
    <sha1>7e61045adc08c415d0c11db74e64ee557b454fbc</sha1>
  </revision>
  <revision>
    <id>1427</id>
    <parentid>1426</parentid>
    <timestamp>2008-11-29T15:37:05Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Policy considerations */ see RFC 3461</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4348" xml:space="preserve">A '''forwarding recipe''' is the procedural data by which a mail server can build a new envelope for an existing message before re-injecting it into the mail system. It includes the forwarded address that the original message bore, one or more new recipient addresses to whom the re-injected message is destined, and a policy. The policy determines the new envelope sender address, at least.

== Common forwarding recipes ==
Historically, recipes were written in [http://www.sendmail.org/ sendmail]'s &lt;code&gt;.forward&lt;/code&gt; files in a recipient's home directory, in order to elicit specific forwarding behavior from the server when a message is received at a given mailbox. Recipes have to be addressable by their forwarded address, so that the software can find any relevant recipe upon message reception. Obviously, the software that implements the SMTP server dictates the format that recipes have to comply. Depending on the implementation, the data that conceptually makes up a recipe may be spread among several files.

A pipe character (&lt;code&gt;|&lt;/code&gt;) in a &lt;code&gt;.forward&lt;/code&gt; file allows executing external programs. Similar concepts work for [http://www.qmail.org/man/man5/dot-qmail.html .qmail] and [http://www.courier-mta.org/dot-courier.html .courier]. A forwarding recipe may consist of
&lt;pre&gt;
| sendmail -f postmaster@example.org newrecipient@example.com
&lt;/pre&gt;
Notice that the forwarded address is implied by the location on disc where the recipe is written. In addition, the behavior triggered by messages bouncing to &lt;code&gt;postmaster@example.org&lt;/code&gt; is conceptually part of this recipe but is specified somewhere else.

Courier-MTA comes with a delivery agent, [http://www.courier-mta.org/maildrop.html maildrop], that implements a local filtering engine with its own programming language. It allows to implement forwarding recipes that are configurable at different levels; that is, more easily maintainable.

== Quest for agreement ==
A forwarding recipe introduces a new segment in the message path, which should be considered within the recipient's realm. In fact, the ''newrecipient'' address is [[wp:personally identifiable information]] of its owner, therefore its owner should have explicitly given a permission to use it in a certain way. That permission, also called ''opt-in'', is not routinely asked for. Even when it is, e.g. when subscribing to a mailing list, the relevant forwarding recipe is stored at the forwarding host only. [[Forwarding agreement]]s are proposed to obviate this limitation and let a forwarding recipe be known and acted upon by its owner, directly from the target host.

== Policy considerations ==
In its simplest form, a forwarding recipe may be difficult to manage. The complexity may increase depending on who and how can create mailboxes and recipes on the system, what spam filtering options are available, and spam reporting mechanisms.

On a small system where only the postmaster creates mailboxes and recipes, for example, a recipe as exemplified above may make sense. Upon receiving a delivery failure, the postmaster should decide whether to drop the recipe as the target address becomes unavailable or to advise the final recipient that the relevant mailbox is full. Larger systems will require to automate that behavior, therefore it becomes necessary to define exactly when and how each operation is performed. For example, a policy can specify a different behavior for a mailbox full situation if an alternative email address or, say, an SMS-enabled phone number are available for advising the final recipient.

A policy may contain various configuration items. It can provide for a number of different states, so that the server can stop receiving new mail in certain cases, possibly requiring that appropriate local responses are given, e.g.:
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;, or 
251  User not local; will forward to &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

Two flags are as follows:
* '''enabled''': mail is accepted, and
* '''non-disclosure''': the target address shall never be revealed.

As a forwarding recipe's policy is limited to local behavior, the ''non-disclosure'' flag affects the text in the server response, and do DSNs and MDNs as for lists. See RFC 3461, ''5.2.7.4 confidential forwarding addresses''; RFC 3798, ''6.2. Privacy''; RFC 3885.</text>
    <sha1>f4ed2dca323b7359875cacdce6e777887c8a0b20</sha1>
  </revision>
  <revision>
    <id>1453</id>
    <parentid>1427</parentid>
    <timestamp>2008-12-06T15:10:14Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Envelope sender tweak */ new subsection</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6056" xml:space="preserve">A '''forwarding recipe''' is the procedural data by which a mail server can build a new envelope for an existing message before re-injecting it into the mail system. It includes the forwarded address that the original message bore, one or more new recipient addresses to whom the re-injected message is destined, and a policy. The policy determines the new envelope sender address, at least.

== Common forwarding recipes ==
Historically, recipes were written in [http://www.sendmail.org/ sendmail]'s &lt;code&gt;.forward&lt;/code&gt; files in a recipient's home directory, in order to elicit specific forwarding behavior from the server when a message is received at a given mailbox. Recipes have to be addressable by their forwarded address, so that the software can find any relevant recipe upon message reception. Obviously, the software that implements the SMTP server dictates the format that recipes have to comply. Depending on the implementation, the data that conceptually makes up a recipe may be spread among several files.

A pipe character (&lt;code&gt;|&lt;/code&gt;) in a &lt;code&gt;.forward&lt;/code&gt; file allows executing external programs. Similar concepts work for [http://www.qmail.org/man/man5/dot-qmail.html .qmail] and [http://www.courier-mta.org/dot-courier.html .courier]. A forwarding recipe may consist of
&lt;pre&gt;
| sendmail -f postmaster@example.org newrecipient@example.com
&lt;/pre&gt;
Notice that the forwarded address is implied by the location on disc where the recipe is written. In addition, the behavior triggered by messages bouncing to &lt;code&gt;postmaster@example.org&lt;/code&gt; is conceptually part of this recipe but is specified somewhere else.

Courier-MTA comes with a delivery agent, [http://www.courier-mta.org/maildrop.html maildrop], that implements a local filtering engine with its own programming language. It allows to implement forwarding recipes that are configurable at different levels; that is, more easily maintainable.

== Quest for agreement ==
A forwarding recipe introduces a new segment in the message path, which should be considered within the recipient's realm. In fact, the ''newrecipient'' address is [[wp:personally identifiable information]] of its owner, therefore its owner should have explicitly given a permission to use it in a certain way. That permission, also called ''opt-in'', is not routinely asked for. Even when it is, e.g. when subscribing to a mailing list, the relevant forwarding recipe is stored at the forwarding host only. [[Forwarding agreement]]s are proposed to obviate this limitation and let a forwarding recipe be known and acted upon by its owner, directly from the target host.

=== Envelope sender tweak ===
An easy technique to let the sending software know that a message is being forwarded is by changing the envelope sender to some special value that is only understood within the host/ADMD. For example&lt;code&gt;
 &amp;nbsp;| sendmail -f ff=&lt;i&gt;keyword&lt;/i&gt;=&lt;i&gt;param&lt;/i&gt;=postmaster@example.org newrecipient@example.com&lt;/code&gt;
The line above provides a keyword and a parameter for using an existing forwarding agreement, or start negotiating one. The sending software, upon seeing that the remote MX accepts the ''ff'' model, shall search a local database for a record corresponding to &lt;code&gt;newrecipient@example.com&lt;/code&gt;, the remote MX, and the keyword parameter. That record is considered a ''complement'' of the forwarding recipe.

If the record is found and contains an id/password for logging in, the sending software recovers the original envelope sender from the ''Return-Path'' header and forwards the message according to this model. For ongoing negotiations, the record may contain an indication to either queue the message or send it normally until the negotiation completes. Otherwise, the keyword and parameter can be used to load a configurated environment and launch the first step of the negotiation. In this case the return code indicates whether to queue the message or sending it normally.

Sending the message normally, which is also done in case the remote MX does not support ''FF'', implies using the default envelope sender, in this case &lt;code&gt;postmaster@example.org&lt;/code&gt;. The tweaked envelope sender never leaves the relevant host. However, it may be set on an internal host inside the same ADMD in case the existing forwarding recipe is not on a boundary host.

== Policy considerations ==
In its simplest form, a forwarding recipe may be difficult to manage. The complexity may increase depending on who and how can create mailboxes and recipes on the system, what spam filtering options are available, and spam reporting mechanisms.

On a small system where only the postmaster creates mailboxes and recipes, for example, a recipe as exemplified above may make sense. Upon receiving a delivery failure, the postmaster should decide whether to drop the recipe as the target address becomes unavailable or to advise the final recipient that the relevant mailbox is full. Larger systems will require to automate that behavior, therefore it becomes necessary to define exactly when and how each operation is performed. For example, a policy can specify a different behavior for a mailbox full situation if an alternative email address or, say, an SMS-enabled phone number are available for advising the final recipient.

A policy may contain various configuration items. It can provide for a number of different states, so that the server can stop receiving new mail in certain cases, possibly requiring that appropriate local responses are given, e.g.:
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;, or 
251  User not local; will forward to &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

Two flags are as follows:
* '''enabled''': mail is accepted, and
* '''non-disclosure''': the target address shall never be revealed.

As a forwarding recipe's policy is limited to local behavior, the ''non-disclosure'' flag affects the text in the server response, and do DSNs and MDNs as for lists. See RFC 3461, ''5.2.7.4 confidential forwarding addresses''; RFC 3798, ''6.2. Privacy''; RFC 3885.</text>
    <sha1>90669d907de589a61450c7312c6e827a65a5b687</sha1>
  </revision>
</page>
<page arvcontinue="">
  <title>forwarding agreement</title>
  <ns>0</ns>
  <id>11</id>
  <revision>
    <id>1423</id>
    <timestamp>2008-11-22T13:08:15Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>start new page</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="3605" xml:space="preserve">A ''forwarding agreement'' is the procedural data that matches a [[forwarding recipe]]. It contains a user-id and password pair, the forwarder's ID, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Establishing a forwarding agreement ==
An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the password changing URL and obtain a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. When automated, the process should conclude rather quickly; an SMTP implementation that realizes an agreement is missing may even run the above procedure on the fly.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP pages under https transport. The certificate and its signing authority can be taken into account when deciding to grant the agreement.

Thus far, we have defined the following ones:
* the EHLO advertised URL,
* the password changing URL, and
* the policy negotiation URL at the forwarder's.

== Maintaining the agreement ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated user is granted permission for the given recipient, thus indexing by forwarder-ID and recipient is necessary. Note that the recipient address given here may well be an alias.

Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, indexing by user-ID is also necessary. The policy negotiation URL must be capable of supplying similar queries, so that it is possible to recursively browse all the mail address that eventually result in mail arriving to the given mailbox.

Obviously, the primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. As that is part of the forwarding recipe, the termination record may optionally be kept for a certain time, in order to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.</text>
    <sha1>99deaf3eaa636454ebf887884bb16b3557254dd8</sha1>
  </revision>
  <revision>
    <id>1428</id>
    <parentid>1423</parentid>
    <timestamp>2008-11-29T16:52:38Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Policy considerations */ add new section</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="3864" xml:space="preserve">A ''forwarding agreement'' is the procedural data that matches a [[forwarding recipe]]. It contains a user-id and password pair, the forwarder's ID, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Establishing a forwarding agreement ==
An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the password changing URL and obtain a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. When automated, the process should conclude rather quickly; an SMTP implementation that realizes an agreement is missing may even run the above procedure on the fly.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP pages under https transport. The certificate and its signing authority can be taken into account when deciding to grant the agreement.

Thus far, we have defined the following ones:
* the EHLO advertised URL,
* the password changing URL, and
* the policy negotiation URL at the forwarder's.

== Maintaining the agreement ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated user is granted permission for the given recipient, thus indexing by forwarder-ID and recipient is necessary. Note that the recipient address given here may well be an alias.

Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, indexing by user-ID is also necessary. The policy negotiation URL must be capable of supplying similar queries, so that it is possible to recursively browse all the mail address that eventually result in mail arriving to the given mailbox.

Obviously, the primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. As that is part of the forwarding recipe, the termination record may optionally be kept for a certain time, in order to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==

The policy shall prescribe what [[boundary filter]]s the forwarder enforces for a specific recipient. DNSBL or SPF checks should not be done for forwarded messages.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>49de7c82c2c865456b407baf2391d102e472469e</sha1>
  </revision>
  <revision>
    <id>1444</id>
    <parentid>1428</parentid>
    <timestamp>2008-12-05T11:12:16Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Definition */ bold</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="3880" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains a user-id and password pair, the forwarder's ID, the category, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Establishing a forwarding agreement ==
An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the password changing URL and obtain a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. When automated, the process should conclude rather quickly; an SMTP implementation that realizes an agreement is missing may even run the above procedure on the fly.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP pages under https transport. The certificate and its signing authority can be taken into account when deciding to grant the agreement.

Thus far, we have defined the following ones:
* the EHLO advertised URL,
* the password changing URL, and
* the policy negotiation URL at the forwarder's.

== Maintaining the agreement ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated user is granted permission for the given recipient, thus indexing by forwarder-ID and recipient is necessary. Note that the recipient address given here may well be an alias.

Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, indexing by user-ID is also necessary. The policy negotiation URL must be capable of supplying similar queries, so that it is possible to recursively browse all the mail address that eventually result in mail arriving to the given mailbox.

Obviously, the primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. As that is part of the forwarding recipe, the termination record may optionally be kept for a certain time, in order to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==

The policy shall prescribe what [[boundary filter]]s the forwarder enforces for a specific recipient. DNSBL or SPF checks should not be done for forwarded messages.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>9cdba505e5b912c4cbfbef9ca887b6e4715aff16</sha1>
  </revision>
  <revision>
    <id>1445</id>
    <parentid>1444</parentid>
    <timestamp>2008-12-05T11:44:47Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Data fields */ insert new section</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4787" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains a user-id and password pair, the forwarder's ID, the category, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''.

The ''user-id'' may be the remote alias name, the list-id, or the newsletter name.

The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for automatically granting agreements. In addition, when sending multiple messages in the same session a forwarder may change the user-id by using the AUTH Parameter to the MAIL FROM command, if both share the same forwarder-ID.

The ''category'' identifies what type of forwarding recipe corresponds to the agreement. Possible values include
* fixed, that is manually edited configuration data to single or multiple recipients,
* mailing list, and
* newsletter.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the password changing URL and obtain a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. When automated, the process should conclude rather quickly; an SMTP implementation that realizes an agreement is missing may even run the above procedure on the fly.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP pages under https transport. The certificate and its signing authority can be taken into account when deciding to grant the agreement.

Thus far, we have defined the following ones:
* the EHLO advertised URL,
* the password changing URL, and
* the policy negotiation URL at the forwarder's.

== Maintaining the agreement ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated user is granted permission for the given recipient, thus indexing by forwarder-ID and recipient is necessary. Note that the recipient address given here may well be an alias.

Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, indexing by user-ID is also necessary. The policy negotiation URL must be capable of supplying similar queries, so that it is possible to recursively browse all the mail address that eventually result in mail arriving to the given mailbox.

Obviously, the primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. As that is part of the forwarding recipe, the termination record may optionally be kept for a certain time, in order to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==

The policy shall prescribe what [[boundary filter]]s the forwarder enforces for a specific recipient. DNSBL or SPF checks should not be done for forwarded messages.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>83837803cb3b0de6c00179438064df8131214f85</sha1>
  </revision>
  <revision>
    <id>1446</id>
    <parentid>1445</parentid>
    <timestamp>2008-12-05T14:45:31Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>ID vs. user-id</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6119" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and password pair, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''.

The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for logging in. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. Possible categories are
* single recipient static,
* multiple recipient static,
* mailing list, and
* newsletter.

The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the password changing URL and obtain a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP pages under https transport. The certificate and its signing authority can be taken into account when deciding to grant the agreement.

Thus far, we have defined the following ones:
* the EHLO advertised URL,
* the password changing URL, and
* the policy negotiation URL at the sender's.

== Maintaining the agreement ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for the given recipient, thus indexing by agreement-ID and user-ID is necessary.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail address that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. As that is part of the forwarding recipe, the termination record may optionally be kept for a certain time, in order to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SMTP AUTH mechanism being used to log in, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>b3a1980e5587aa7ff75610431c9a541c80a846a4</sha1>
  </revision>
  <revision>
    <id>1450</id>
    <parentid>1446</parentid>
    <timestamp>2008-12-05T15:15:21Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Data fields */ add a category for backup MX</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6132" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and password pair, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''.

The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for logging in. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. Possible categories are
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, and
* backup MX.

The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the password changing URL and obtain a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP pages under https transport. The certificate and its signing authority can be taken into account when deciding to grant the agreement.

Thus far, we have defined the following ones:
* the EHLO advertised URL,
* the password changing URL, and
* the policy negotiation URL at the sender's.

== Maintaining the agreement ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for the given recipient, thus indexing by agreement-ID and user-ID is necessary.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail address that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. As that is part of the forwarding recipe, the termination record may optionally be kept for a certain time, in order to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SMTP AUTH mechanism being used to log in, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>2ea87493b318f44f75fa40bd65749e07e947224b</sha1>
  </revision>
  <revision>
    <id>1451</id>
    <parentid>1450</parentid>
    <timestamp>2008-12-05T15:40:32Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Using and maintaining agreements */ renamed section</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6265" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and password pair, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''.

The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for logging in. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. Possible categories are
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, and
* backup MX.

The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the password changing URL and obtain a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP pages under https transport. The certificate and its signing authority can be taken into account when deciding to grant the agreement.

Thus far, we have defined the following ones:
* the EHLO advertised URL,
* the password changing URL, and
* the policy negotiation URL at the sender's.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for the given recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail address that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. As that is part of the forwarding recipe, the termination record may optionally be kept for a certain time, in order to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SMTP AUTH mechanism being used to log in, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>8007d0616ce660098d6159aed7162e32f76617a1</sha1>
  </revision>
  <revision>
    <id>1454</id>
    <parentid>1451</parentid>
    <timestamp>2008-12-06T15:10:50Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Establishing a forwarding agreement */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6539" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and password pair, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''.

The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for logging in. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. Possible categories are
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, and
* backup MX.

The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the password changing URL and obtain a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP pages under https transport. The certificate and its signing authority can be taken into account when deciding to grant the agreement.

Thus far, we have defined the following ones:
* the EHLO advertised URL,
* the password changing URL, and
* the policy negotiation URL at the sender's.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for the given recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail address that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. As that is part of the forwarding recipe, the termination record may optionally be kept for a certain time, in order to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SMTP AUTH mechanism being used to log in, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>1ad6b7bd3812f0974d495598bb0caa85b7b72bf9</sha1>
  </revision>
</page>
<page arvcontinue="">
  <title>Forwarding agreement</title>
  <ns>0</ns>
  <id>12</id>
  <revision>
    <id>1424</id>
    <timestamp>2008-11-29T11:51:15Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Redirecting to [[forwarding agreement]]</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="34" xml:space="preserve">#redirect [[forwarding agreement]]</text>
    <sha1>99c7d6600ab8a4cabc11baeb6a6ee3ed367d08dc</sha1>
  </revision>
</page>
<page arvcontinue="">
  <title>boundary filter</title>
  <ns>0</ns>
  <id>13</id>
  <revision>
    <id>1429</id>
    <timestamp>2008-11-29T16:56:54Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>new (short) page</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="177" xml:space="preserve">A '''boundary filter''' is a mail filter that is preferably operated at the [[boundary]] between the sender and the recipient realms.

== Known boundary filters ==
* DNSBL
* SPF</text>
    <sha1>4ab17e00fe8c2c66daaebb4e96e53dc0ffb24a06</sha1>
  </revision>
  <revision>
    <id>1434</id>
    <parentid>1429</parentid>
    <timestamp>2008-12-01T16:54:40Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>expanded</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2488" xml:space="preserve">A '''boundary filter''' is a mail filter that is preferably operated at the [[boundary]] between the originating and the receiving networks.

== DNSBL ==
DNS Block Lists are IP addresses of known spammers or compromised machines. Looking up the remote IP of an incoming SMTP connection is commonly used for avoiding a good percentage of spam. Obviously, this operation has to be done at the boundary. Otherwise, only the last forwarder's IP address can be checked.

Some users don't want their mail to be filtered against some or all DNSBL, though. They possibly counter spam by avoiding to publish their email address. A server may accomplish such kind of request by setting an environment flag in case the remote IP is blacklisted, then check user's preferences on each RCPT command. When this can be done, the negotiation of a [[forwarding agreement]] should include a list of available DNSBL, letting the target host choose on behalf of the user which of them should be enabled or disabled. This option makes more sense for single-recipient forwarding recipes than for, say, mailing lists.

== SPF ==
Sender Policy Framework checks must be done at the boundary. Blocking forged addresses appeared a good idea in 2003. However, some argue that SPF breaks forwarding; other counter-argue that forwarding is broken since RFC 1123.

Requiring that the forwarder carries out SPF checks, adds ''Received-SPF'' headers, and rejects messages that ''fail'' the SPF authorization, is expected to be a typical requirement of the [[forwarding agreement]] negotiation.

Negotiating a forwarding agreement may set the ''non-disclosure'' flag in the corresponding forwarding recipe under certain circumstances. In that case, the forwarder must set the envelope sender to ''null'' or to a bounce address provided by the target host. For all other cases, there is no need to use SRS or any other sender replacement, since the forwarder is exempted from SPF checks under the agreement.

== Other filters ==
Anti-virus, DKIM, S/MIME, and other forms of authentication or authorization can be performed anywhere along the path. Running them sooner rather than later is trading bandwidth for CPU cycles. ''FixForwarding'' doesn't prescribe any particular behavior for these filters, encouraging hosts to run them as they routinely do. However, the negotiation stage may provide for exchanging a path for reporting message-specific or statistical information related to these filters, e.g. a feedback loop.</text>
    <sha1>d6f01e00cbae0809b24206dd2b10d83077db8fd5</sha1>
  </revision>
</page>
<page arvcontinue="">
  <title>boundary</title>
  <ns>0</ns>
  <id>14</id>
  <revision>
    <id>1430</id>
    <timestamp>2008-11-29T17:00:28Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>New page: There is a well determined '''boundary''' between the sender and the recipient of a given mail message.  == Definition == The boundary is defined by the MX records of the recipient's domai...</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="566" xml:space="preserve">There is a well determined '''boundary''' between the sender and the recipient of a given mail message.

== Definition ==
The boundary is defined by the MX records of the recipient's domain in the ''global'' DNS. Along the path of a given message, there is exactly one point where an MTA looks up the global DNS, determines a target host in the recipient domain's MX, and delivers to one of them. The boundary between the two realms lays in the middle of that hop. (Further hops from a backup MX to a higher priority one are conventionally in the recipient's realm.)</text>
    <sha1>09e77576aa20c694237f4b4cd389b219d0349427</sha1>
  </revision>
  <revision>
    <id>1431</id>
    <parentid>1430</parentid>
    <timestamp>2008-11-30T15:16:59Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Restructured, rephrased, reworded</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2440" xml:space="preserve">In a given message path, there is a well determined '''boundary''' between the mail originating network (MON) and the mail receiving network (MRN). It lies where the first MX is looked up in the global DNS in order to determine the receiver for the next hop.

== Topology ==
The boundary is defined by the MX records of the recipient's domain in the ''global'' DNS. Internal DNS views may provide for outgoing mail paths, as an alternative to MTA-specific configuration. Because DNS is global, the domain servers are uniquely identified.

The same message may follow different paths at different times, depending on connection availability, DNS changes, and DNS randomization. In addition, when the recipient changes, the path changes widely. It can well happen that the same host is on one side of the boundary for message A, and it happens to be on the other side for message B, even if both messages end up to the same target host. On the other hand, the whole path may consist of a single server, resulting in a degenerated boundary inside it.

This topology is not necessarily related to ADministrative Management Domains (ADMDs).

== Forwarders ==
Relays performing alias expansion are considered part of the MRN, if they use the target address legitimately.

== Backup MXes ==
A message may pass through a backup MX if a direct connection to the target server is not available. The backup MX is considered part of the MRN, even if it currently does not have a list of valid users.

The way backup MXes currently operate generates backscatter. This, and the fact that connections are often very reliable, results in diminished use of backup MXes. Only large networks operate them, and they are usually in the same ADMD.

It is possible that the [[solution proposed]] here results in enhanced backup MXes operations. A backup MX has an implicit list of valid mailboxes that comprises any possible address within the given domain(s). However, it still needs to gather forwarding agreements explicitly. That would result in having an almost complete list of users. It may reply with a 4xx code for new users that are not in the agreements database. Additional mechanisms are needed (e.g. temporary blacklists of addresses, maximum allowed queries per time period) to make that behavior smooth.

== See Also ==
*[http://www.openspf.org/Community/Glossary SPF Community Glossary] has some more terminology and mentions where it originated.</text>
    <sha1>9f62b3cfd729c9790c5a7c7c8ff0b0c443da71ec</sha1>
  </revision>
  <revision>
    <id>1449</id>
    <parentid>1431</parentid>
    <timestamp>2008-12-05T15:11:25Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Topology */ expand on ADMD</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2710" xml:space="preserve">In a given message path, there is a well determined '''boundary''' between the mail originating network (MON) and the mail receiving network (MRN). It lies where the first MX is looked up in the global DNS in order to determine the receiver for the next hop.

== Topology ==
The boundary is defined by the MX records of the recipient's domain in the ''global'' DNS. Internal DNS views may provide for outgoing mail paths, as an alternative to MTA-specific configuration. Because DNS is global, the domain servers are uniquely identified.

The same message may follow different paths at different times, depending on connection availability, DNS changes, and DNS randomization. In addition, when the recipient changes, the path changes widely. It can well happen that the same host is on one side of the boundary for message A, and it happens to be on the other side for message B, even if both messages end up to the same target host. On the other hand, the whole path may consist of a single server, resulting in a degenerated boundary inside it.

This topology is not necessarily related to ADministrative Management Domains (ADMDs). On the one hand, hosts belonging to an ADMD may end up not being involved in any inter-domain forwarding. On the other hand, hosts that don't belong to an ADMD may negotiate an agreement and enjoy the amount of trust that is required to perform inter-domain forwarding.

== Forwarders ==
Relays performing alias expansion are considered part of the MRN, if they use the target address legitimately.

== Backup MXes ==
A message may pass through a backup MX if a direct connection to the target server is not available. The backup MX is considered part of the MRN, even if it currently does not have a list of valid users.

The way backup MXes currently operate generates backscatter. This, and the fact that connections are often very reliable, results in diminished use of backup MXes. Only large networks operate them, and they are usually in the same ADMD.

It is possible that the [[solution proposed]] here results in enhanced backup MXes operations. A backup MX has an implicit list of valid mailboxes that comprises any possible address within the given domain(s). However, it still needs to gather forwarding agreements explicitly. That would result in having an almost complete list of users. It may reply with a 4xx code for new users that are not in the agreements database. Additional mechanisms are needed (e.g. temporary blacklists of addresses, maximum allowed queries per time period) to make that behavior smooth.

== See Also ==
*[http://www.openspf.org/Community/Glossary SPF Community Glossary] has some more terminology and mentions where it originated.</text>
    <sha1>176bf3507558012110be78ff04eab58f6c593235</sha1>
  </revision>
</page>
<page arvcontinue="">
  <title>forwarding</title>
  <ns>0</ns>
  <id>15</id>
  <revision>
    <id>1432</id>
    <timestamp>2008-11-30T16:07:12Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Redirecting to [[Forwarding]]</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="24" xml:space="preserve">#redirect [[Forwarding]]</text>
    <sha1>b58000fadf725c1a53342b7704796020ec59fc33</sha1>
  </revision>
</page>
<page arvcontinue="">
  <title>solution proposed</title>
  <ns>0</ns>
  <id>16</id>
  <revision>
    <id>1433</id>
    <timestamp>2008-11-30T16:14:20Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>new page</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="1614" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a host obtains an id/password pair that it can use to relay messages for a given user via SMTP AUTH on the relevant server. The receiver maintains a list of agreements matching the corresponding records in the alias expansion lists at the senders'.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection for certain cases. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops. Thus, agreements provide for a unified interface for unsubscribe, report spam, generic feedback, and preference setting for the end user, that is the owner of the relevant mailboxes.

As complicate as setting up a forwarding agreement may be, using it is as cheap as possible. In facts, a local database lookup on both sides should suffice in most cases.

== History ==
The idea arose in a discussion originated on the spf-discuss list in January 2008. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG and Courier-users mailing lists, where it didn't receive much attention: The idea itself is not ''very'' complicated, but it has to be described slowly. Thus this site born, in fall 2008.</text>
    <sha1>ac32b095059df56085b7c8e122e0be656ab24430</sha1>
  </revision>
  <revision>
    <id>1435</id>
    <parentid>1433</parentid>
    <timestamp>2008-12-01T17:55:57Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Anti-Spam */ new section</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2356" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a host obtains an id/password pair that it can use to relay messages for a given user via SMTP AUTH on the relevant server. The receiver maintains a list of agreements matching the corresponding records in the alias expansion lists at the senders'.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection for certain cases. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops. Thus, agreements provide for a unified interface for unsubscribe, report spam, generic feedback, and preference setting for the end user, that is the owner of the relevant mailboxes.

As complicate as setting up a forwarding agreement may be, using it is as cheap as possible. In facts, a local database lookup on both sides should suffice in most cases.

== Anti-Spam ==
The major contribution of this solution against spam consists in enabling [[boundary filter]]s. Some of those filter, in turn, don-t aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' email address would confront them with their actions.

The usual definition of spam, "unsolicited bulk email", does not distinguish those who use of false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

== History ==
The idea arose in a discussion originated on the spf-discuss list in January 2008. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG and Courier-users mailing lists, where it didn't receive much attention: The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born, in fall 2008.</text>
    <sha1>724520f365c3395138d8091d70a14ccfc9fe28a1</sha1>
  </revision>
  <revision>
    <id>1436</id>
    <parentid>1435</parentid>
    <timestamp>2008-12-01T18:21:30Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Anti-Spam */ typo</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2356" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a host obtains an id/password pair that it can use to relay messages for a given user via SMTP AUTH on the relevant server. The receiver maintains a list of agreements matching the corresponding records in the alias expansion lists at the senders'.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection for certain cases. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops. Thus, agreements provide for a unified interface for unsubscribe, report spam, generic feedback, and preference setting for the end user, that is the owner of the relevant mailboxes.

As complicate as setting up a forwarding agreement may be, using it is as cheap as possible. In facts, a local database lookup on both sides should suffice in most cases.

== Anti-Spam ==
The major contribution of this solution against spam consists in enabling [[boundary filter]]s. Some of those filter, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' email address would confront them with their actions.

The usual definition of spam, "unsolicited bulk email", does not distinguish those who use of false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

== History ==
The idea arose in a discussion originated on the spf-discuss list in January 2008. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG and Courier-users mailing lists, where it didn't receive much attention: The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born, in fall 2008.</text>
    <sha1>32a13a82c326237a5bb092d6e8af7e46ad52e5c9</sha1>
  </revision>
  <revision>
    <id>1437</id>
    <parentid>1436</parentid>
    <timestamp>2008-12-01T18:22:20Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Anti-Spam */ wording</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2355" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a host obtains an id/password pair that it can use to relay messages for a given user via SMTP AUTH on the relevant server. The receiver maintains a list of agreements matching the corresponding records in the alias expansion lists at the senders'.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection for certain cases. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops. Thus, agreements provide for a unified interface for unsubscribe, report spam, generic feedback, and preference setting for the end user, that is the owner of the relevant mailboxes.

As complicate as setting up a forwarding agreement may be, using it is as cheap as possible. In facts, a local database lookup on both sides should suffice in most cases.

== Anti-Spam ==
The major contribution of this solution against spam consists in enabling [[boundary filter]]s. Some of those filter, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their actions.

The usual definition of spam, "unsolicited bulk email", does not distinguish those who use of false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

== History ==
The idea arose in a discussion originated on the spf-discuss list in January 2008. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG and Courier-users mailing lists, where it didn't receive much attention: The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born, in fall 2008.</text>
    <sha1>f1448d12ef9d24d5b5c5c51040830b36220d0934</sha1>
  </revision>
  <revision>
    <id>1438</id>
    <parentid>1437</parentid>
    <timestamp>2008-12-01T18:23:02Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Anti-Spam */ wording</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2364" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a host obtains an id/password pair that it can use to relay messages for a given user via SMTP AUTH on the relevant server. The receiver maintains a list of agreements matching the corresponding records in the alias expansion lists at the senders'.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection for certain cases. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops. Thus, agreements provide for a unified interface for unsubscribe, report spam, generic feedback, and preference setting for the end user, that is the owner of the relevant mailboxes.

As complicate as setting up a forwarding agreement may be, using it is as cheap as possible. In facts, a local database lookup on both sides should suffice in most cases.

== Anti-Spam ==
The major contribution of this solution against spam consists in enabling [[boundary filter]]s. Some of those filter, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

The usual definition of spam, "unsolicited bulk email", does not distinguish those who use of false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

== History ==
The idea arose in a discussion originated on the spf-discuss list in January 2008. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG and Courier-users mailing lists, where it didn't receive much attention: The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born, in fall 2008.</text>
    <sha1>8bc700c75155b11783d4fb6c7083ccfd84715761</sha1>
  </revision>
  <revision>
    <id>1439</id>
    <parentid>1438</parentid>
    <timestamp>2008-12-01T18:23:51Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Anti-Spam */ wording</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2372" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a host obtains an id/password pair that it can use to relay messages for a given user via SMTP AUTH on the relevant server. The receiver maintains a list of agreements matching the corresponding records in the alias expansion lists at the senders'.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection for certain cases. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops. Thus, agreements provide for a unified interface for unsubscribe, report spam, generic feedback, and preference setting for the end user, that is the owner of the relevant mailboxes.

As complicate as setting up a forwarding agreement may be, using it is as cheap as possible. In facts, a local database lookup on both sides should suffice in most cases.

== Anti-Spam ==
The major contribution of this solution against spam consists in enabling [[boundary filter]]s. Some of those filter, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

The usual definition of spam, "unsolicited bulk email", does not distinguish between spammers who use false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

== History ==
The idea arose in a discussion originated on the spf-discuss list in January 2008. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG and Courier-users mailing lists, where it didn't receive much attention: The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born, in fall 2008.</text>
    <sha1>ba3dca004bd8a58adfd85b232d4c563d680a7ad9</sha1>
  </revision>
  <revision>
    <id>1440</id>
    <parentid>1439</parentid>
    <timestamp>2008-12-01T18:25:19Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Anti-Spam */ typo</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2364" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a host obtains an id/password pair that it can use to relay messages for a given user via SMTP AUTH on the relevant server. The receiver maintains a list of agreements matching the corresponding records in the alias expansion lists at the senders'.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection for certain cases. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops. Thus, agreements provide for a unified interface for unsubscribe, report spam, generic feedback, and preference setting for the end user, that is the owner of the relevant mailboxes.

As complicate as setting up a forwarding agreement may be, using it is as cheap as possible. In facts, a local database lookup on both sides should suffice in most cases.

== Anti-Spam ==
The major contribution of this solution against spam consists in enabling [[boundary filter]]s. Some of those filter, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

The usual definition of spam, "unsolicited bulk email", does not distinguish spammers who use false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

== History ==
The idea arose in a discussion originated on the spf-discuss list in January 2008. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG and Courier-users mailing lists, where it didn't receive much attention: The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born, in fall 2008.</text>
    <sha1>f1443cd849bd50a69323d2abb0fa38e96773d2ae</sha1>
  </revision>
  <revision>
    <id>1441</id>
    <parentid>1440</parentid>
    <timestamp>2008-12-05T10:30:42Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Anti-Spam effect */ "effect", +/- sections</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4266" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a host obtains an id/password pair that it can use to relay messages for a given user via SMTP AUTH on the relevant server. The receiver maintains a list of agreements matching the corresponding records in the alias expansion lists at the senders'.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection for certain cases. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops. Thus, agreements provide for a unified interface for unsubscribe, report spam, generic feedback, and preference setting for the end user, that is the owner of the relevant mailboxes.

As complicate as setting up a forwarding agreement may be, using it is as cheap as possible. In facts, a local database lookup on both sides should suffice in most cases.

== Pluses ==
This solution attempts to impose some order in the ''real and extensive diversity of email transfer scenarios'', as Dave Crocker describes it[http://www.irtf.org/pipermail/asrg/2008-December/004192.html].

=== Anti-Spam effects ===
The major effect of this solution against spam consists in enabling [[boundary filter]]s. Some of those filters, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

A second effect is to improve legal stances. The usual definition of spam, "unsolicited bulk email", does not distinguish spammers who use false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

=== Unified unsubscribe ===
The data gathered with each agreement can be easily made available to UIs aiming at enumerating users subscriptions, possibly recursively. Agreements can be presented in historical order and/or by category, allowing users to change preferences and unsubscribe.

Rather than hitting "report spam" buttons on a per-message basis, users could target the whole series of messages that arrived under a given agreement. Such semantic shift may help to disambiguate an attempt to report that a single message is spam, not the newsletter it belongs to.

== Minuses ==
Managing agreements is an additional burden. Are we ready?

=== False security ===
Automatically stipulated agreements are not bullet proof. Questionable senders may sneak in and send messages that formally look like having passed through SMTP AUTH. Although it may actually be easier for a server to monitor messages grouping them by ''forwarder-id'' rather than (or in addition to) IP address, downstream software may erroneously assume that a ''Received'' or ''Authentication-Results'' headers exhibiting smpt.auth data imply a well identified sender.

=== Easy attack path ===
Since receiving hosts promise to skip some boundary checks for forwarded messages, spammers may just use a zombie and an easily obtained TLS certificate to stipulate forwarding agreements. Then they can send spam more easily to those hosts. If it is too easy to obtain an agreement, this solution won't work. However, it is possible to invest more time and precautions during the handshake than it would for single messages: that's the challenge hereby proposed.

== History ==
The idea arose in a discussion originated on the spf-discuss list in January 2008. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG and Courier-users mailing lists, where it didn't receive much attention: The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born, in fall 2008.</text>
    <sha1>0918dc6d4fe8d3776bb2de0dc60eaed857fdfa08</sha1>
  </revision>
  <revision>
    <id>1442</id>
    <parentid>1441</parentid>
    <timestamp>2008-12-05T10:58:19Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Summary */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4479" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a sender obtains an id/password pair that it can use to relay messages destined to a given user via SMTP AUTH on the relevant server. The receiver maintains a list of agreements matching the corresponding elements of the alias expansion lists at the senders'.

Agreements are classified into different categories, e.g., single forwarding, newsletters, mailing lists. An agreement is required for each target user and for each subscription mechanism. For example, if sender A runs a mailing list and two newsletters, and two users at receiver B subscribe to all of them, then B will store six agreements for A, just like A has six recipes for B.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection for certain cases. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops.

As complicate as setting up a forwarding agreement may be, using it is as cheap as possible. In facts, a local database lookup on both sides should suffice in most cases.

== Pluses ==
This solution attempts to impose some order in the ''real and extensive diversity of email transfer scenarios'', as Dave Crocker describes it[http://www.irtf.org/pipermail/asrg/2008-December/004192.html].

=== Anti-Spam effects ===
The major effect of this solution against spam consists in enabling [[boundary filter]]s. Some of those filters, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

A second effect is to improve legal stances. The usual definition of spam, "unsolicited bulk email", does not distinguish spammers who use false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

=== Unified unsubscribe ===
The data gathered with each agreement can be easily made available to UIs aiming at enumerating users subscriptions, possibly recursively. Agreements can be presented in historical order and/or by category, allowing users to change preferences and unsubscribe.

Rather than hitting "report spam" buttons on a per-message basis, users could target the whole series of messages that arrived under a given agreement. Such semantic shift may help to disambiguate an attempt to report that a single message is spam, not the newsletter it belongs to.

== Minuses ==
Managing agreements is an additional burden. Are we ready?

=== False security ===
Automatically stipulated agreements are not bullet proof. Questionable senders may sneak in and send messages that formally look like having passed through SMTP AUTH. Although it may actually be easier for a server to monitor messages grouping them by ''forwarder-id'' rather than (or in addition to) IP address, downstream software may erroneously assume that a ''Received'' or ''Authentication-Results'' headers exhibiting smpt.auth data imply a well identified sender.

=== Easy attack path ===
Since receiving hosts promise to skip some boundary checks for forwarded messages, spammers may just use a zombie and an easily obtained TLS certificate to stipulate forwarding agreements. Then they can send spam more easily to those hosts. If it is too easy to obtain an agreement, this solution won't work. However, it is possible to invest more time and precautions during the handshake than it would for single messages: that's the challenge hereby proposed.

== History ==
The idea arose in a discussion originated on the spf-discuss list in January 2008. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG and Courier-users mailing lists, where it didn't receive much attention: The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born, in fall 2008.</text>
    <sha1>8735418041ebf8775ca8dc414a4cd8ac03a058ea</sha1>
  </revision>
  <revision>
    <id>1447</id>
    <parentid>1442</parentid>
    <timestamp>2008-12-05T14:52:21Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Summary */ wording</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4467" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a sender obtains an SMTP AUTH id/password pair that it can use to relay messages destined to a given user on the relevant server. The receiver maintains a list of agreements matching the corresponding elements of the alias expansion lists at the senders'.

Agreements are classified into different categories, e.g., single forwarding, newsletters, mailing lists. An agreement is required for each target user and for each subscription. For example, if sender A runs one mailing list and two newsletters, and two users at receiver B subscribe to all of them, then B will store six agreements for A, just like A has six recipes for B.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection for certain cases. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops.

As complicate as setting up a forwarding agreement may be, using it is as cheap as possible. In facts, a local database lookup on both sides should suffice in most cases.

== Pluses ==
This solution attempts to impose some order in the ''real and extensive diversity of email transfer scenarios'', as Dave Crocker describes it[http://www.irtf.org/pipermail/asrg/2008-December/004192.html].

=== Anti-Spam effects ===
The major effect of this solution against spam consists in enabling [[boundary filter]]s. Some of those filters, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

A second effect is to improve legal stances. The usual definition of spam, "unsolicited bulk email", does not distinguish spammers who use false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

=== Unified unsubscribe ===
The data gathered with each agreement can be easily made available to UIs aiming at enumerating users subscriptions, possibly recursively. Agreements can be presented in historical order and/or by category, allowing users to change preferences and unsubscribe.

Rather than hitting "report spam" buttons on a per-message basis, users could target the whole series of messages that arrived under a given agreement. Such semantic shift may help to disambiguate an attempt to report that a single message is spam, not the newsletter it belongs to.

== Minuses ==
Managing agreements is an additional burden. Are we ready?

=== False security ===
Automatically stipulated agreements are not bullet proof. Questionable senders may sneak in and send messages that formally look like having passed through SMTP AUTH. Although it may actually be easier for a server to monitor messages grouping them by ''forwarder-id'' rather than (or in addition to) IP address, downstream software may erroneously assume that a ''Received'' or ''Authentication-Results'' headers exhibiting smpt.auth data imply a well identified sender.

=== Easy attack path ===
Since receiving hosts promise to skip some boundary checks for forwarded messages, spammers may just use a zombie and an easily obtained TLS certificate to stipulate forwarding agreements. Then they can send spam more easily to those hosts. If it is too easy to obtain an agreement, this solution won't work. However, it is possible to invest more time and precautions during the handshake than it would for single messages: that's the challenge hereby proposed.

== History ==
The idea arose in a discussion originated on the spf-discuss list in January 2008. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG and Courier-users mailing lists, where it didn't receive much attention: The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born, in fall 2008.</text>
    <sha1>c673cbf0213d635fdbd2f1abf3f07a1647de624d</sha1>
  </revision>
  <revision>
    <id>1448</id>
    <parentid>1447</parentid>
    <timestamp>2008-12-05T14:55:34Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* False security */ typo</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4465" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a sender obtains an SMTP AUTH id/password pair that it can use to relay messages destined to a given user on the relevant server. The receiver maintains a list of agreements matching the corresponding elements of the alias expansion lists at the senders'.

Agreements are classified into different categories, e.g., single forwarding, newsletters, mailing lists. An agreement is required for each target user and for each subscription. For example, if sender A runs one mailing list and two newsletters, and two users at receiver B subscribe to all of them, then B will store six agreements for A, just like A has six recipes for B.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection for certain cases. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops.

As complicate as setting up a forwarding agreement may be, using it is as cheap as possible. In facts, a local database lookup on both sides should suffice in most cases.

== Pluses ==
This solution attempts to impose some order in the ''real and extensive diversity of email transfer scenarios'', as Dave Crocker describes it[http://www.irtf.org/pipermail/asrg/2008-December/004192.html].

=== Anti-Spam effects ===
The major effect of this solution against spam consists in enabling [[boundary filter]]s. Some of those filters, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

A second effect is to improve legal stances. The usual definition of spam, "unsolicited bulk email", does not distinguish spammers who use false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

=== Unified unsubscribe ===
The data gathered with each agreement can be easily made available to UIs aiming at enumerating users subscriptions, possibly recursively. Agreements can be presented in historical order and/or by category, allowing users to change preferences and unsubscribe.

Rather than hitting "report spam" buttons on a per-message basis, users could target the whole series of messages that arrived under a given agreement. Such semantic shift may help to disambiguate an attempt to report that a single message is spam, not the newsletter it belongs to.

== Minuses ==
Managing agreements is an additional burden. Are we ready?

=== False security ===
Automatically stipulated agreements are not bullet proof. Questionable senders may sneak in and send messages that formally look like having passed through SMTP AUTH. Although it may actually be easier for a server to monitor messages grouping them by ''forwarder-id'' rather than (or in addition to) IP address, downstream software may erroneously assume that ''Received'' or ''Authentication-Results'' headers exhibiting smpt.auth data imply a well identified sender.

=== Easy attack path ===
Since receiving hosts promise to skip some boundary checks for forwarded messages, spammers may just use a zombie and an easily obtained TLS certificate to stipulate forwarding agreements. Then they can send spam more easily to those hosts. If it is too easy to obtain an agreement, this solution won't work. However, it is possible to invest more time and precautions during the handshake than it would for single messages: that's the challenge hereby proposed.

== History ==
The idea arose in a discussion originated on the spf-discuss list in January 2008. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG and Courier-users mailing lists, where it didn't receive much attention: The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born, in fall 2008.</text>
    <sha1>dc9d1ee783787df249c11fd72cef1a9482b80308</sha1>
  </revision>
  <revision>
    <id>1452</id>
    <parentid>1448</parentid>
    <timestamp>2008-12-06T14:16:07Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Summary */ mention what triggers FF</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5196" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a sender obtains an SMTP AUTH id/password pair that it can use to relay messages destined to a given user on the relevant server. The receiver maintains a list of agreements matching the corresponding elements of the alias expansion lists at the senders'.

Agreements are classified into different categories, e.g., single forwarding, newsletters, mailing lists. An agreement is required for each target user and for each subscription. For example, if sender A runs one mailing list and two newsletters, and two users at receiver B subscribe to all of them, then B will store six agreements for A, just like A has six recipes for B.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection for certain cases. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops.

This model of forwarding is triggered by a small tweak and a light SMTP extension. The tweak on the sender side consists of a peculiar encoding of the envelope sender that lets the sending software know that a message is being forwarded and provides a parameter for negotiating or an agreement or using an existing one. It requires to set the ''-f'' command switch properly on the forwarding recipe. The tweaked envelope sender only lives locally, on the relevant host or ADMD. The extension on the receiver side is an EHLO keyword to let the sending software know that a specific receiver being contacted is also willing to use forwarding agreements.

As complicate as setting up a forwarding agreement may be, using it is as cheap as possible. In case the agreement has already been negotiated, the sender finds the id/password in a local database, and the remote receiver authenticates it normally.

== Pluses ==
This solution attempts to impose some order in the ''real and extensive diversity of email transfer scenarios'', as Dave Crocker describes it[http://www.irtf.org/pipermail/asrg/2008-December/004192.html].

=== Anti-Spam effects ===
The major effect of this solution against spam consists in enabling [[boundary filter]]s. Some of those filters, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

A second effect is to improve legal stances. The usual definition of spam, "unsolicited bulk email", does not distinguish spammers who use false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

=== Unified unsubscribe ===
The data gathered with each agreement can be easily made available to UIs aiming at enumerating users subscriptions, possibly recursively. Agreements can be presented in historical order and/or by category, allowing users to change preferences and unsubscribe.

Rather than hitting "report spam" buttons on a per-message basis, users could target the whole series of messages that arrived under a given agreement. Such semantic shift may help to disambiguate an attempt to report that a single message is spam, not the newsletter it belongs to.

== Minuses ==
Managing agreements is an additional burden. Are we ready?

=== False security ===
Automatically stipulated agreements are not bullet proof. Questionable senders may sneak in and send messages that formally look like having passed through SMTP AUTH. Although it may actually be easier for a server to monitor messages grouping them by ''forwarder-id'' rather than (or in addition to) IP address, downstream software may erroneously assume that ''Received'' or ''Authentication-Results'' headers exhibiting smpt.auth data imply a well identified sender.

=== Easy attack path ===
Since receiving hosts promise to skip some boundary checks for forwarded messages, spammers may just use a zombie and an easily obtained TLS certificate to stipulate forwarding agreements. Then they can send spam more easily to those hosts. If it is too easy to obtain an agreement, this solution won't work. However, it is possible to invest more time and precautions during the handshake than it would for single messages: that's the challenge hereby proposed.

== History ==
The idea arose in a discussion originated on the spf-discuss list in January 2008. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG and Courier-users mailing lists, where it didn't receive much attention: The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born, in fall 2008.</text>
    <sha1>0a71d16a41e39ce306e1d6bd851464b6206b3850</sha1>
  </revision>
</page>
<page arvcontinue="20081206153830|1455">
  <title>forwarding recipe</title>
  <ns>0</ns>
  <id>10</id>
  <revision>
    <id>1455</id>
    <parentid>1453</parentid>
    <timestamp>2008-12-06T15:38:30Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Common forwarding recipes */ subsections</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6449" xml:space="preserve">A '''forwarding recipe''' is the procedural data by which a mail server can build a new envelope for an existing message before re-injecting it into the mail system. It includes the forwarded address that the original message bore, one or more new recipient addresses to whom the re-injected message is destined, and a policy. The policy determines the new envelope sender address, at least.

== Common forwarding recipes ==
=== Static recipes ===
Historically, recipes were written in [http://www.sendmail.org/ sendmail]'s &lt;code&gt;.forward&lt;/code&gt; files in a recipient's home directory, in order to elicit specific forwarding behavior from the server when a message is received at a given mailbox. Recipes have to be addressable by their forwarded address, so that the software can find any relevant recipe upon message reception. Obviously, the software that implements the SMTP server dictates the format that recipes have to comply. Depending on the implementation, the data that conceptually makes up a recipe may be spread among several files.

A pipe character (&lt;code&gt;|&lt;/code&gt;) in a &lt;code&gt;.forward&lt;/code&gt; file allows executing external programs. Similar concepts work for [http://www.qmail.org/man/man5/dot-qmail.html .qmail] and [http://www.courier-mta.org/dot-courier.html .courier]. A forwarding recipe may consist of &lt;code&gt;
 &amp;nbsp;| sendmail -f postmaster@example.org newrecipient@example.com&lt;/code&gt;

Notice that the forwarded address is implied by the location on disc where the recipe is written. In addition, the behavior triggered by messages bouncing to &lt;code&gt;postmaster@example.org&lt;/code&gt; is conceptually part of this recipe but is specified somewhere else.

=== Newsletters and mailing lists ===
Dynamic recipes are managed by specialized software. Such software has well defined schemata to precisely define what messages are forwarded to what addresses. A number of ''best practices'' documents exists that specify how to reliably send bulk mail, e.g. [http://mipassoc.org/spamops/index.html MIPAssoc]. In case the model proposed here will be adopted, it may be added to the list of things to do, but it will have to be done on a per-package basis.

=== Backup MXes ===
A backup MX also does forwarding. What is special in it, is that forwarding recipes are ''implicit''. See also [[boundary#Backup MXes]].

== Quest for agreement ==
A forwarding recipe introduces a new segment in the message path, which should be considered within the recipient's realm. In fact, the ''newrecipient'' address is [[wp:personally identifiable information]] of its owner, therefore its owner should have explicitly given a permission to use it in a certain way. That permission, also called ''opt-in'', is not routinely asked for. Even when it is, e.g. when subscribing to a mailing list, the relevant forwarding recipe is stored at the forwarding host only. [[Forwarding agreement]]s are proposed to obviate this limitation and let a forwarding recipe be known and acted upon by its owner, directly from the target host.

=== Envelope sender tweak ===
An easy technique to let the sending software know that a message is being forwarded is by changing the envelope sender to some special value that is only understood within the host/ADMD. For example&lt;code&gt;
 &amp;nbsp;| sendmail -f ff=&lt;i&gt;keyword&lt;/i&gt;=&lt;i&gt;param&lt;/i&gt;=postmaster@example.org newrecipient@example.com&lt;/code&gt;
The line above provides a keyword and a parameter for using an existing forwarding agreement, or start negotiating one. The sending software, upon seeing that the remote MX accepts the ''ff'' model, shall search a local database for a record corresponding to &lt;code&gt;newrecipient@example.com&lt;/code&gt;, the remote MX, and the keyword parameter. That record is considered a ''complement'' of the forwarding recipe.

If the record is found and contains an id/password for logging in, the sending software recovers the original envelope sender from the ''Return-Path'' header and forwards the message according to this model. For ongoing negotiations, the record may contain an indication to either queue the message or send it normally until the negotiation completes. Otherwise, the keyword and parameter can be used to load a configurated environment and launch the first step of the negotiation. In this case the return code indicates whether to queue the message or sending it normally.

Sending the message normally, which is also done in case the remote MX does not support ''FF'', implies using the default envelope sender, in this case &lt;code&gt;postmaster@example.org&lt;/code&gt;. The tweaked envelope sender never leaves the relevant host. However, it may be set on an internal host inside the same ADMD in case the existing forwarding recipe is not on a boundary host.

== Policy considerations ==
In its simplest form, a forwarding recipe may be difficult to manage. The complexity may increase depending on who and how can create mailboxes and recipes on the system, what spam filtering options are available, and spam reporting mechanisms.

On a small system where only the postmaster creates mailboxes and recipes, for example, a recipe as exemplified above may make sense. Upon receiving a delivery failure, the postmaster should decide whether to drop the recipe as the target address becomes unavailable or to advise the final recipient that the relevant mailbox is full. Larger systems will require to automate that behavior, therefore it becomes necessary to define exactly when and how each operation is performed. For example, a policy can specify a different behavior for a mailbox full situation if an alternative email address or, say, an SMS-enabled phone number are available for advising the final recipient.

A policy may contain various configuration items. It can provide for a number of different states, so that the server can stop receiving new mail in certain cases, possibly requiring that appropriate local responses are given, e.g.:
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;, or 
251  User not local; will forward to &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

Two flags are as follows:
* '''enabled''': mail is accepted, and
* '''non-disclosure''': the target address shall never be revealed.

As a forwarding recipe's policy is limited to local behavior, the ''non-disclosure'' flag affects the text in the server response, and do DSNs and MDNs as for lists. See RFC 3461, ''5.2.7.4 confidential forwarding addresses''; RFC 3798, ''6.2. Privacy''; RFC 3885.</text>
    <sha1>b06d0159460152a653a9c430fc11cc692e453d7b</sha1>
  </revision>
</page>
<page arvcontinue="20081206153830|1455">
  <title>solution proposed</title>
  <ns>0</ns>
  <id>16</id>
  <revision>
    <id>1456</id>
    <parentid>1452</parentid>
    <timestamp>2008-12-06T15:57:04Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Summary */ wording/typo</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5251" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a sender obtains an SMTP AUTH id/password pair that it can use to relay messages destined to a given user on the relevant server. The receiver maintains a list of agreements, matching the corresponding elements at the senders' alias expansion lists.

Agreements are classified into different categories, e.g., static ''.forward'' files, newsletters, mailing lists. An agreement is required for each target user and for each subscription. For example, if sender A runs one mailing list and two newsletters, and two users at receiver B subscribe to all of them, then B will store six agreements for A, just like A has six recipes for B.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection for certain cases. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops.

This model of forwarding can be triggered by a local tweak and a light SMTP extension. The tweak on the sender side consists of a peculiar encoding of the envelope sender that lets the sending software know that a message is being forwarded, and provides a parameter for either negotiating an agreement or using an existing one. That requires to set the ''-f'' command switch accordingly. The tweaked envelope sender only lives locally, i.e. on the relevant host or ADMD. The extension on the receiver side is an EHLO keyword to let the sending software know that the specific MX being contacted is also willing to use forwarding agreements.

The negotiation required to establish a forwarding agreement can be quite complicate, specially if it is the first agreement between two organizations. By contrast, using an existing agreement is very cheap: the sender finds the id/password pair in a local database, and the remote MX authenticates it normally.

== Pluses ==
This solution attempts to impose some order in the ''real and extensive diversity of email transfer scenarios'', as Dave Crocker describes it[http://www.irtf.org/pipermail/asrg/2008-December/004192.html].

=== Anti-Spam effects ===
The major effect of this solution against spam consists in enabling [[boundary filter]]s. Some of those filters, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

A second effect is to improve legal stances. The usual definition of spam, "unsolicited bulk email", does not distinguish spammers who use false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

=== Unified unsubscribe ===
The data gathered with each agreement can be easily made available to UIs aiming at enumerating users subscriptions, possibly recursively. Agreements can be presented in historical order and/or by category, allowing users to change preferences and unsubscribe.

Rather than hitting "report spam" buttons on a per-message basis, users could target the whole series of messages that arrived under a given agreement. Such semantic shift may help to disambiguate an attempt to report that a single message is spam, not the newsletter it belongs to.

== Minuses ==
Managing agreements is an additional burden. Are we ready?

=== False security ===
Automatically stipulated agreements are not bullet proof. Questionable senders may sneak in and send messages that formally look like having passed through SMTP AUTH. Although it may actually be easier for a server to monitor messages grouping them by ''forwarder-id'' rather than (or in addition to) IP address, downstream software may erroneously assume that ''Received'' or ''Authentication-Results'' headers exhibiting smpt.auth data imply a well identified sender.

=== Easy attack path ===
Since receiving hosts promise to skip some boundary checks for forwarded messages, spammers may just use a zombie and an easily obtained TLS certificate to stipulate forwarding agreements. Then they can send spam more easily to those hosts. If it is too easy to obtain an agreement, this solution won't work. However, it is possible to invest more time and precautions during the handshake than it would for single messages: that's the challenge hereby proposed.

== History ==
The idea arose in a discussion originated on the spf-discuss list in January 2008. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG and Courier-users mailing lists, where it didn't receive much attention: The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born, in fall 2008.</text>
    <sha1>3488d5396d3727ceacea4d3b571385c38cd5f2b6</sha1>
  </revision>
  <revision>
    <id>1457</id>
    <parentid>1456</parentid>
    <timestamp>2008-12-06T15:59:02Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Easy attack path */ wording</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5263" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a sender obtains an SMTP AUTH id/password pair that it can use to relay messages destined to a given user on the relevant server. The receiver maintains a list of agreements, matching the corresponding elements at the senders' alias expansion lists.

Agreements are classified into different categories, e.g., static ''.forward'' files, newsletters, mailing lists. An agreement is required for each target user and for each subscription. For example, if sender A runs one mailing list and two newsletters, and two users at receiver B subscribe to all of them, then B will store six agreements for A, just like A has six recipes for B.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection for certain cases. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops.

This model of forwarding can be triggered by a local tweak and a light SMTP extension. The tweak on the sender side consists of a peculiar encoding of the envelope sender that lets the sending software know that a message is being forwarded, and provides a parameter for either negotiating an agreement or using an existing one. That requires to set the ''-f'' command switch accordingly. The tweaked envelope sender only lives locally, i.e. on the relevant host or ADMD. The extension on the receiver side is an EHLO keyword to let the sending software know that the specific MX being contacted is also willing to use forwarding agreements.

The negotiation required to establish a forwarding agreement can be quite complicate, specially if it is the first agreement between two organizations. By contrast, using an existing agreement is very cheap: the sender finds the id/password pair in a local database, and the remote MX authenticates it normally.

== Pluses ==
This solution attempts to impose some order in the ''real and extensive diversity of email transfer scenarios'', as Dave Crocker describes it[http://www.irtf.org/pipermail/asrg/2008-December/004192.html].

=== Anti-Spam effects ===
The major effect of this solution against spam consists in enabling [[boundary filter]]s. Some of those filters, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

A second effect is to improve legal stances. The usual definition of spam, "unsolicited bulk email", does not distinguish spammers who use false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

=== Unified unsubscribe ===
The data gathered with each agreement can be easily made available to UIs aiming at enumerating users subscriptions, possibly recursively. Agreements can be presented in historical order and/or by category, allowing users to change preferences and unsubscribe.

Rather than hitting "report spam" buttons on a per-message basis, users could target the whole series of messages that arrived under a given agreement. Such semantic shift may help to disambiguate an attempt to report that a single message is spam, not the newsletter it belongs to.

== Minuses ==
Managing agreements is an additional burden. Are we ready?

=== False security ===
Automatically stipulated agreements are not bullet proof. Questionable senders may sneak in and send messages that formally look like having passed through SMTP AUTH. Although it may actually be easier for a server to monitor messages grouping them by ''forwarder-id'' rather than (or in addition to) IP address, downstream software may erroneously assume that ''Received'' or ''Authentication-Results'' headers exhibiting smpt.auth data imply a well identified sender.

=== Easy attack path ===
Since receiving hosts promise to skip some boundary checks for forwarded messages, spammers may just use a zombie and an easily obtained TLS certificate to stipulate forwarding agreements. Then they can send spam more easily to those hosts. If it is too easy to obtain an agreement, this solution won't work. However, it is possible to invest more time and precautions during the negotiation handshake than it would for single messages: that's the challenge hereby proposed.

== History ==
The idea arose in a discussion originated on the spf-discuss list in January 2008. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG and Courier-users mailing lists, where it didn't receive much attention: The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born, in fall 2008.</text>
    <sha1>394c0953c11940838cb66c184d61be46c14aefc8</sha1>
  </revision>
  <revision>
    <id>1458</id>
    <parentid>1457</parentid>
    <timestamp>2008-12-07T10:11:57Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Summary */ wording</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5258" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a sender obtains an SMTP AUTH id/password pair that it can use to relay messages destined to a given user on the relevant server. The receiver maintains a list of agreements, matching the corresponding elements at the senders' alias expansion lists.

Agreements are classified into different categories, e.g., static ''.forward'' files, newsletters, mailing lists. An agreement is required for each target user and for each subscription. For example, if sender A runs one mailing list and two newsletters, and two users at receiver B subscribe to all of them, then B will store six agreements for A, just like A has six recipes for B.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection as desired. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops.

This model of forwarding can be triggered by means of a local tweak and a light SMTP extension. The tweak on the sender side consists of a local encoding of the envelope sender that lets the sending software know that a message is being forwarded, and provides a parameter for either negotiating an agreement or using an existing one. That requires to set the ''-f'' command switch accordingly. The tweaked envelope sender only lives locally, i.e. on the relevant host or ADMD. The extension on the receiver side is an EHLO keyword to let the sending software know that the specific MX being contacted is also willing to use forwarding agreements.

The negotiation required to establish a forwarding agreement can be quite complicate, especially for the first agreement between two organizations. By contrast, using an existing agreement is very cheap: the sender finds the id/password pair in a local database, and the remote MX authenticates it normally.

== Pluses ==
This solution attempts to impose some order in the ''real and extensive diversity of email transfer scenarios'', as Dave Crocker describes it[http://www.irtf.org/pipermail/asrg/2008-December/004192.html].

=== Anti-Spam effects ===
The major effect of this solution against spam consists in enabling [[boundary filter]]s. Some of those filters, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

A second effect is to improve legal stances. The usual definition of spam, "unsolicited bulk email", does not distinguish spammers who use false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

=== Unified unsubscribe ===
The data gathered with each agreement can be easily made available to UIs aiming at enumerating users subscriptions, possibly recursively. Agreements can be presented in historical order and/or by category, allowing users to change preferences and unsubscribe.

Rather than hitting "report spam" buttons on a per-message basis, users could target the whole series of messages that arrived under a given agreement. Such semantic shift may help to disambiguate an attempt to report that a single message is spam, not the newsletter it belongs to.

== Minuses ==
Managing agreements is an additional burden. Are we ready?

=== False security ===
Automatically stipulated agreements are not bullet proof. Questionable senders may sneak in and send messages that formally look like having passed through SMTP AUTH. Although it may actually be easier for a server to monitor messages grouping them by ''forwarder-id'' rather than (or in addition to) IP address, downstream software may erroneously assume that ''Received'' or ''Authentication-Results'' headers exhibiting smpt.auth data imply a well identified sender.

=== Easy attack path ===
Since receiving hosts promise to skip some boundary checks for forwarded messages, spammers may just use a zombie and an easily obtained TLS certificate to stipulate forwarding agreements. Then they can send spam more easily to those hosts. If it is too easy to obtain an agreement, this solution won't work. However, it is possible to invest more time and precautions during the negotiation handshake than it would for single messages: that's the challenge hereby proposed.

== History ==
The idea arose in a discussion originated on the spf-discuss list in January 2008. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG and Courier-users mailing lists, where it didn't receive much attention: The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born, in fall 2008.</text>
    <sha1>7f9df5de8637b57b14a6ba753ee5ae7a9a67d167</sha1>
  </revision>
  <revision>
    <id>1459</id>
    <parentid>1458</parentid>
    <timestamp>2008-12-08T13:29:16Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* History */ add links</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5608" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a sender obtains an SMTP AUTH id/password pair that it can use to relay messages destined to a given user on the relevant server. The receiver maintains a list of agreements, matching the corresponding elements at the senders' alias expansion lists.

Agreements are classified into different categories, e.g., static ''.forward'' files, newsletters, mailing lists. An agreement is required for each target user and for each subscription. For example, if sender A runs one mailing list and two newsletters, and two users at receiver B subscribe to all of them, then B will store six agreements for A, just like A has six recipes for B.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection as desired. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops.

This model of forwarding can be triggered by means of a local tweak and a light SMTP extension. The tweak on the sender side consists of a local encoding of the envelope sender that lets the sending software know that a message is being forwarded, and provides a parameter for either negotiating an agreement or using an existing one. That requires to set the ''-f'' command switch accordingly. The tweaked envelope sender only lives locally, i.e. on the relevant host or ADMD. The extension on the receiver side is an EHLO keyword to let the sending software know that the specific MX being contacted is also willing to use forwarding agreements.

The negotiation required to establish a forwarding agreement can be quite complicate, especially for the first agreement between two organizations. By contrast, using an existing agreement is very cheap: the sender finds the id/password pair in a local database, and the remote MX authenticates it normally.

== Pluses ==
This solution attempts to impose some order in the ''real and extensive diversity of email transfer scenarios'', as Dave Crocker describes it[http://www.irtf.org/pipermail/asrg/2008-December/004192.html].

=== Anti-Spam effects ===
The major effect of this solution against spam consists in enabling [[boundary filter]]s. Some of those filters, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

A second effect is to improve legal stances. The usual definition of spam, "unsolicited bulk email", does not distinguish spammers who use false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

=== Unified unsubscribe ===
The data gathered with each agreement can be easily made available to UIs aiming at enumerating users subscriptions, possibly recursively. Agreements can be presented in historical order and/or by category, allowing users to change preferences and unsubscribe.

Rather than hitting "report spam" buttons on a per-message basis, users could target the whole series of messages that arrived under a given agreement. Such semantic shift may help to disambiguate an attempt to report that a single message is spam, not the newsletter it belongs to.

== Minuses ==
Managing agreements is an additional burden. Are we ready?

=== False security ===
Automatically stipulated agreements are not bullet proof. Questionable senders may sneak in and send messages that formally look like having passed through SMTP AUTH. Although it may actually be easier for a server to monitor messages grouping them by ''forwarder-id'' rather than (or in addition to) IP address, downstream software may erroneously assume that ''Received'' or ''Authentication-Results'' headers exhibiting smpt.auth data imply a well identified sender.

=== Easy attack path ===
Since receiving hosts promise to skip some boundary checks for forwarded messages, spammers may just use a zombie and an easily obtained TLS certificate to stipulate forwarding agreements. Then they can send spam more easily to those hosts. If it is too easy to obtain an agreement, this solution won't work. However, it is possible to invest more time and precautions during the negotiation handshake than it would for single messages: that's the challenge hereby proposed.

== History ==
The ''ff'' idea arose in a discussion originated on the spf-discuss list in January 2008[http://www.listbox.com/member/archive/735/2008/01/sort/thread_rev/page/1/entry/11:265/20080131110008:4871D6CE-D015-11DC-8216-54C5B46F41FF/]. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG[http://www.nabble.com/Yet-another-attempt-to-fix-forwarding-td15177052.html] and Courier-users[http://www.mail-archive.com/courier-users@lists.sourceforge.net/msg30908.html] mailing lists, where it just originated more or less (respectively) responses on SPF/SRS topics only. The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born, in fall 2008.</text>
    <sha1>7a6ded0ff67b32054f956766bac75613c11205d2</sha1>
  </revision>
  <revision>
    <id>1462</id>
    <parentid>1459</parentid>
    <timestamp>2008-12-08T15:10:39Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* History */ registered by end of Jan: omit "fall"</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5594" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a sender obtains an SMTP AUTH id/password pair that it can use to relay messages destined to a given user on the relevant server. The receiver maintains a list of agreements, matching the corresponding elements at the senders' alias expansion lists.

Agreements are classified into different categories, e.g., static ''.forward'' files, newsletters, mailing lists. An agreement is required for each target user and for each subscription. For example, if sender A runs one mailing list and two newsletters, and two users at receiver B subscribe to all of them, then B will store six agreements for A, just like A has six recipes for B.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection as desired. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops.

This model of forwarding can be triggered by means of a local tweak and a light SMTP extension. The tweak on the sender side consists of a local encoding of the envelope sender that lets the sending software know that a message is being forwarded, and provides a parameter for either negotiating an agreement or using an existing one. That requires to set the ''-f'' command switch accordingly. The tweaked envelope sender only lives locally, i.e. on the relevant host or ADMD. The extension on the receiver side is an EHLO keyword to let the sending software know that the specific MX being contacted is also willing to use forwarding agreements.

The negotiation required to establish a forwarding agreement can be quite complicate, especially for the first agreement between two organizations. By contrast, using an existing agreement is very cheap: the sender finds the id/password pair in a local database, and the remote MX authenticates it normally.

== Pluses ==
This solution attempts to impose some order in the ''real and extensive diversity of email transfer scenarios'', as Dave Crocker describes it[http://www.irtf.org/pipermail/asrg/2008-December/004192.html].

=== Anti-Spam effects ===
The major effect of this solution against spam consists in enabling [[boundary filter]]s. Some of those filters, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

A second effect is to improve legal stances. The usual definition of spam, "unsolicited bulk email", does not distinguish spammers who use false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

=== Unified unsubscribe ===
The data gathered with each agreement can be easily made available to UIs aiming at enumerating users subscriptions, possibly recursively. Agreements can be presented in historical order and/or by category, allowing users to change preferences and unsubscribe.

Rather than hitting "report spam" buttons on a per-message basis, users could target the whole series of messages that arrived under a given agreement. Such semantic shift may help to disambiguate an attempt to report that a single message is spam, not the newsletter it belongs to.

== Minuses ==
Managing agreements is an additional burden. Are we ready?

=== False security ===
Automatically stipulated agreements are not bullet proof. Questionable senders may sneak in and send messages that formally look like having passed through SMTP AUTH. Although it may actually be easier for a server to monitor messages grouping them by ''forwarder-id'' rather than (or in addition to) IP address, downstream software may erroneously assume that ''Received'' or ''Authentication-Results'' headers exhibiting smpt.auth data imply a well identified sender.

=== Easy attack path ===
Since receiving hosts promise to skip some boundary checks for forwarded messages, spammers may just use a zombie and an easily obtained TLS certificate to stipulate forwarding agreements. Then they can send spam more easily to those hosts. If it is too easy to obtain an agreement, this solution won't work. However, it is possible to invest more time and precautions during the negotiation handshake than it would for single messages: that's the challenge hereby proposed.

== History ==
The ''ff'' idea arose in a discussion originated on the spf-discuss list in January 2008[http://www.listbox.com/member/archive/735/2008/01/sort/thread_rev/page/1/entry/11:265/20080131110008:4871D6CE-D015-11DC-8216-54C5B46F41FF/]. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG[http://www.nabble.com/Yet-another-attempt-to-fix-forwarding-td15177052.html] and Courier-users[http://www.mail-archive.com/courier-users@lists.sourceforge.net/msg30908.html] mailing lists, where it just originated more or less (respectively) responses on SPF/SRS topics only. The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born.</text>
    <sha1>4de8a4f5249cdf6add658c03f0e92703c7d3c99c</sha1>
  </revision>
  <revision>
    <id>1475</id>
    <parentid>1462</parentid>
    <timestamp>2008-12-23T15:46:34Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Summary */ wording</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5794" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a sender obtains an SMTP AUTH id/password pair that it can use to relay messages destined to a given user on the relevant server. The receiver maintains a list of agreements, matching one-to-one with the corresponding elements at the senders' alias expansion lists.

Agreements are classified into different categories, e.g., static ''.forward'' files, newsletters, mailing lists. An agreement is required for each target user and for each subscription. For example, if sender A runs one mailing list and two newsletters, and two users at receiver B subscribe to all of them, then B will store six agreements for A, just like A has six recipes for B.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection as desired. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops.

This model of forwarding can be triggered by means of a local tweak and a light SMTP extension. The tweak on the sender side consists of a local encoding of the envelope sender that lets the sending software know that a message is being forwarded, and provides a parameter for either negotiating an agreement or using an existing one. This has to be enabled by setting the ''-f'' command switch accordingly, for each recipe. The tweaked envelope sender only lives locally, i.e. on the relevant host or ADMD. The extension on the receiver side is an EHLO keyword to let the sending software know that the specific MX being contacted is also willing to use forwarding agreements.

The negotiation required to establish a forwarding agreement can be quite complicate, especially for the first agreement between two organizations. It provides for a three-way handshake during which the servers exchange the relevant credentials and URLs required to re-negotiate the agreement. By contrast, normal use of an existing agreement is very cheap: the sender finds the id/password pair in a local database, and the remote MX authenticates it normally.

== Pluses ==
This solution attempts to impose some order in the ''real and extensive diversity of email transfer scenarios'', as Dave Crocker describes it[http://www.irtf.org/pipermail/asrg/2008-December/004192.html].

=== Anti-Spam effects ===
The major effect of this solution against spam consists in enabling [[boundary filter]]s. Some of those filters, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

A second effect is to improve legal stances. The usual definition of spam, "unsolicited bulk email", does not distinguish spammers who use false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

=== Unified unsubscribe ===
The data gathered with each agreement can be easily made available to UIs aiming at enumerating users subscriptions, possibly recursively. Agreements can be presented in historical order and/or by category, allowing users to change preferences and unsubscribe.

Rather than hitting "report spam" buttons on a per-message basis, users could target the whole series of messages that arrived under a given agreement. Such semantic shift may help to disambiguate an attempt to report that a single message is spam, not the newsletter it belongs to.

== Minuses ==
Managing agreements is an additional burden. Are we ready?

=== False security ===
Automatically stipulated agreements are not bullet proof. Questionable senders may sneak in and send messages that formally look like having passed through SMTP AUTH. Although it may actually be easier for a server to monitor messages grouping them by ''forwarder-id'' rather than (or in addition to) IP address, downstream software may erroneously assume that ''Received'' or ''Authentication-Results'' headers exhibiting smpt.auth data imply a well identified sender.

=== Easy attack path ===
Since receiving hosts promise to skip some boundary checks for forwarded messages, spammers may just use a zombie and an easily obtained TLS certificate to stipulate forwarding agreements. Then they can send spam more easily to those hosts. If it is too easy to obtain an agreement, this solution won't work. However, it is possible to invest more time and precautions during the negotiation handshake than it would for single messages: that's the challenge hereby proposed.

== History ==
The ''ff'' idea arose in a discussion originated on the spf-discuss list in January 2008[http://www.listbox.com/member/archive/735/2008/01/sort/thread_rev/page/1/entry/11:265/20080131110008:4871D6CE-D015-11DC-8216-54C5B46F41FF/]. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG[http://www.nabble.com/Yet-another-attempt-to-fix-forwarding-td15177052.html] and Courier-users[http://www.mail-archive.com/courier-users@lists.sourceforge.net/msg30908.html] mailing lists, where it just originated more or less (respectively) responses on SPF/SRS topics only. The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born.</text>
    <sha1>9e11c11f614a81ef61b2c32e6cdfd5a45e9de5e2</sha1>
  </revision>
</page>
<page arvcontinue="20081206153830|1455">
  <title>boundary filter</title>
  <ns>0</ns>
  <id>13</id>
  <revision>
    <id>1460</id>
    <parentid>1434</parentid>
    <timestamp>2008-12-08T13:45:53Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* DNSBL */ mention whitelisting the forwarder itself</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2791" xml:space="preserve">A '''boundary filter''' is a mail filter that is preferably operated at the [[boundary]] between the originating and the receiving networks.

== DNSBL ==
DNS Block Lists are IP addresses of known spammers or compromised machines. Looking up the remote IP of an incoming SMTP connection is commonly used for avoiding a good percentage of spam. Obviously, this operation has to be done at the boundary. Otherwise, only the last forwarder's IP address can be checked.

Some users don't want their mail to be filtered against some or all DNSBL, though. They possibly counter spam by avoiding to publish their email address. A server may accomplish such kind of request by setting an environment flag in case the remote IP is blacklisted, then check user's preferences on each RCPT command. When this can be done, the negotiation of a [[forwarding agreement]] should include a list of available DNSBL, letting the target host choose on behalf of the user which of them should be enabled or disabled. This option makes more sense for single-recipient forwarding recipes than for, say, mailing lists.

A completely different requirement is that the receiver whitelists the forwarder itself, in case the latter gets blacklisted. A receiver should only grant such a privilege to hosts that have been thoroughly identified, e.g. gathering trusted administrative and technical contacts during the handshake.

== SPF ==
Sender Policy Framework checks must be done at the boundary. Blocking forged addresses appeared a good idea in 2003. However, some argue that SPF breaks forwarding; other counter-argue that forwarding is broken since RFC 1123.

Requiring that the forwarder carries out SPF checks, adds ''Received-SPF'' headers, and rejects messages that ''fail'' the SPF authorization, is expected to be a typical requirement of the [[forwarding agreement]] negotiation.

Negotiating a forwarding agreement may set the ''non-disclosure'' flag in the corresponding forwarding recipe under certain circumstances. In that case, the forwarder must set the envelope sender to ''null'' or to a bounce address provided by the target host. For all other cases, there is no need to use SRS or any other sender replacement, since the forwarder is exempted from SPF checks under the agreement.

== Other filters ==
Anti-virus, DKIM, S/MIME, and other forms of authentication or authorization can be performed anywhere along the path. Running them sooner rather than later is trading bandwidth for CPU cycles. ''FixForwarding'' doesn't prescribe any particular behavior for these filters, encouraging hosts to run them as they routinely do. However, the negotiation stage may provide for exchanging a path for reporting message-specific or statistical information related to these filters, e.g. a feedback loop.</text>
    <sha1>f209e9adc1923890e61846988b9288b574549adc</sha1>
  </revision>
  <revision>
    <id>1461</id>
    <parentid>1460</parentid>
    <timestamp>2008-12-08T14:27:55Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* SPF */ relationship with</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="3096" xml:space="preserve">A '''boundary filter''' is a mail filter that is preferably operated at the [[boundary]] between the originating and the receiving networks.

== DNSBL ==
DNS Block Lists are IP addresses of known spammers or compromised machines. Looking up the remote IP of an incoming SMTP connection is commonly used for avoiding a good percentage of spam. Obviously, this operation has to be done at the boundary. Otherwise, only the last forwarder's IP address can be checked.

Some users don't want their mail to be filtered against some or all DNSBL, though. They possibly counter spam by avoiding to publish their email address. A server may accomplish such kind of request by setting an environment flag in case the remote IP is blacklisted, then check user's preferences on each RCPT command. When this can be done, the negotiation of a [[forwarding agreement]] should include a list of available DNSBL, letting the target host choose on behalf of the user which of them should be enabled or disabled. This option makes more sense for single-recipient forwarding recipes than for, say, mailing lists.

A completely different requirement is that the receiver whitelists the forwarder itself, in case the latter gets blacklisted. A receiver should only grant such a privilege to hosts that have been thoroughly identified, e.g. gathering trusted administrative and technical contacts during the handshake.

== SPF ==
Sender Policy Framework checks must be done at the boundary. Blocking forged addresses appeared a good idea in 2003. However, some argue that SPF breaks forwarding; other counter-argue that forwarding is broken since RFC 1123.

Requiring that the forwarder carries out SPF checks, adds ''Received-SPF'' headers, and rejects messages that ''fail'' the SPF authorization, is expected to be a typical requirement of the [[forwarding agreement]] negotiation.

Negotiating a forwarding agreement may set the ''non-disclosure'' flag in the corresponding forwarding recipe under certain circumstances. In that case, the forwarder must set the envelope sender to ''null'' or to a bounce address provided by the target host. For all other cases, there is no need to use SRS or any other sender replacement, since the forwarder is exempted from SPF checks under the agreement.

=== N.B.: Relationship with SPF ===
Besides historical considerations, SPF happens to address the question "''who may legally use a domain name?''" That is strictly related with the privacy question "''who may legally use my email address?''" The latter is the main concern of the [[solution proposed]].

== Other filters ==
Anti-virus, DKIM, S/MIME, and other forms of authentication or authorization can be performed anywhere along the path. Running them sooner rather than later is trading bandwidth for CPU cycles. ''FixForwarding'' doesn't prescribe any particular behavior for these filters, encouraging hosts to run them as they routinely do. However, the negotiation stage may provide for exchanging a path for reporting message-specific or statistical information related to these filters, e.g. a feedback loop.</text>
    <sha1>d10487784a41066d73cb01458e6e059f6bcc200b</sha1>
  </revision>
</page>
<page arvcontinue="20081206153830|1455">
  <title>privacy laws</title>
  <ns>0</ns>
  <id>17</id>
  <revision>
    <id>1463</id>
    <timestamp>2008-12-20T10:54:17Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Created page</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2845" xml:space="preserve">By '''privacy laws''' we mean any of the legal frameworks that regulate information privacy in the USA, EU, and several national countries. Although not exactly uniform, the existing bodies of rules tend to converge toward certain principles aimed at protecting people against undiscriminated usage of collected ''personally identifiable information'', a.k.a. ''personal data''.

== Freedom in the digital era ==
Advancements in electronics allow to exercise pervasive and widespread control on what the people do. Digital control can provide for appealing means for implementing commercial practices on unprecedentedly wide scales. While customers used to be able to guard against a shopkeeper foxiness by themselves, they are defenseless when confronted with large business enterprises who systematically exchange their customers' PI information with one another.

As it often happens during the transition from an era to the next, criteria and even laws that have been stipulated in times when their enforcement was provided by radically different means, may become questionable. The efforts undertaken thus far to define the legal terms and the issues implied by the new scenario, are the first chisel blows for establishing the future shape.

The Internet protocols that make this all possible, including SMTP, have necessarily been designed before it all began.

== Implementing the law ==

''Opt-in'' and ''opt-out'' are two key concept for regulating how commercial newsletters may be sent. The SMTP protocol talks about ''mailing lists'', not newsletters. Technically, they are the same thing, since the exact working of the subscribe and unsubscribe operations is not specified rigorously.

RFC 2369 mandates some headers with special URLs. The ''List-Unsubscribe'' header field contains the command to directly unsubscribe from the list. However, mail clients usually don't show it to the user. A possible reason for that uncooperative behavior may lay in the unknown nature of the command, that may expose the user to security risks if programmed by a malicious sender.

In addition, whatever method of subscribe or unsubscribe gets executed, users are given just a notice of the outcome of the operation, that they seldom save or print. The data remains at the lists owners', which makes it hard to take legal stances. There is no need to take legal actions, because legitimate senders always honor users commands; however, such tautological statements contribute to make ''spam'' a fuzzy term.

An email address is considered personally identifiable data. The agreement of its owner is required for storing and using that data. Its owner has the right to amend or delete it. It is the law. The [[solution proposed]] provides for a standard unsubscribe method, and provides for a copy of the users commands to be kept by their ESPs.</text>
    <sha1>8da3d613010802a6f51e301aa0ded803b4adfdc3</sha1>
  </revision>
</page>
<page arvcontinue="20081206153830|1455">
  <title>Main Page</title>
  <ns>0</ns>
  <id>1</id>
  <revision>
    <id>1464</id>
    <parentid>1443</parentid>
    <timestamp>2008-12-20T10:56:14Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* The solution: Standardize forwarding practices */ shortened</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="1557" xml:space="preserve">&lt;big&gt;'''Once upon a time SMTP was a simple protocol...'''&lt;/big&gt;

[[Forwarding]] is a generally used but not thoroughly considered feature of Internet email architecture. Admins and power users have the ability to unilaterally add ''[[forwarding recipe]]s'' onto a server, so that email messages destined to a given mailbox are forwarded or exploded to the recipients thus configured.

In the horrid mess that is Internet Email nowadays, a jungle where illegal spam messages largely outweigh legitimate ones, forwarding stands out as a prominent problem. Let's fix it.

== The problem ==
Savage forwarding produces quite some shortcomings:
* Recipients have no means to directly control the forwarding mechanism.
* Responsibility for injecting spam becomes ambiguous.
* Bounces may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

== The solution: Standardize forwarding practices ==
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?</text>
    <sha1>a577f44097be4aa65c6eb0c351b8db234879f215</sha1>
  </revision>
</page>
<page arvcontinue="20081206153830|1455">
  <title>Forwarding</title>
  <ns>0</ns>
  <id>9</id>
  <revision>
    <id>1465</id>
    <parentid>1422</parentid>
    <timestamp>2008-12-20T11:04:02Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* See also */ added David's link</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="3783" xml:space="preserve">Mail '''forwarding''' is the act of transferring a message from the server where the message recently arrived to another server that is deemed nearer to the intended recipient(s).

== Meaning of the term in this site ==

We focus on two types of message transferring that servers do automatically upon receiving a message: possibly altering the envelope or leaving it intact.

=== Forwarding with a new envelope ===
The receiving server finds a [[forwarding recipe]] corresponding to one of the message's recipient addresses, and it honors it by
* replacing the recipient address with the ones listed in the recipe, and
* replacing the ''sender address'', according to the recipe's policy.

The server address defines the behavior of the email system in the case of delivery failures: Even if the next server will accept the forwarded message, a delivery failure may occur further downstream. In that case, a failure notice should be delivered to the mailbox defined by setting the sender address at this stage. Therefore, there are a few considerations that may affect the policy:
# Should the forwarding recipe be modified as a consequence of delivery failures?
# Should the replaced recipient addresses be made known to the upstream sender?
 
This action is described in section 3.9.2 of &lt;nowiki&gt;RFC 5321&lt;/nowiki&gt;, ''List''. Note that the preceding section 3.9.1 of that RFC, ''Alias'', describes a forwarding method useful for ''intra-domain'' forwarding. See below.

=== Forwarding with the same envelope===
This is the operation that a ''backup MX'' accomplishes to deliver messages to primary MXes of the given domain, where further processing may occur. It may happen that a relay, e.g. the author's outgoing mail server, cannot reach a primary MX for a given recipient. That may occur if the target server is temporarily unreachable. Thus, secondary MXes can cope with network outages.

== Forwarding agreement solution ==
&lt;!-- TODO: add template {{main|Forwarding agreement}} --&gt;
''Main article: [[forwarding agreement]]''

An MX server who accepts such specific form of agreement should advertise it during the SMTP handshake. A forwarder may then choose to come into an agreement, or just submit mail without worrying about reputation and deliverability. Concluding the agreement requires a policy match involving the forwarder and the recipient. End users set their policies specifying relevant options at the target MX, or just accepting the default.

After the agreement has been set up, the forwarder is supplied with a valid user id and password which are only valid for forwarding that kind of mail to the given recipient.

== Other acceptations of ''forwarding'' ==

That term is commonly used for the manual operation initiated by users by clicking on the ''Forward'' button of their MUAs. From the SMTP point of view, that action is not a forwarding, in the sense that the new message will have a new envelope, a new Message-ID, and a possibly altered content.

In addition, '''alias expansion''' is often referred by this term. The main difference between forwarding and alias expansion, according to SMTP, is that the latter does not alter the envelope sender. If the operation is carried out on the same server, it may not undergo a new SMTP transaction, and just write the message to a different location on disc. However, it is still quite common for servers to forward messages badly omitting to properly set a new envelope sender: while technically resembling an alias expansion, ''ill forwarding'' breaks protocols that depend on the envelope sender, e.g. [http://www.openspf.org/ SPF].

== See also ==
* [[wp:Email forwarding]]
* [http://open-mail.org/MHSmodel.html Models for Mail Handling Systems]
* RFC 5321 Simple Mail Transfer Protocol, section 3.9</text>
    <sha1>63aab9eb418e3a9aba28355da637981a4d070271</sha1>
  </revision>
</page>
<page arvcontinue="20081206153830|1455">
  <title>Talk:Forwarding</title>
  <ns>1</ns>
  <id>18</id>
  <revision>
    <id>1466</id>
    <timestamp>2008-12-21T17:20:15Z</timestamp>
    <contributor>
      <username>Macquigg</username>
      <id>2</id>
    </contributor>
    <comment>Definition of Forwarding</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="359" xml:space="preserve">The definition for forwarding needs to be much more limited.  Here is a suggestion:

Forwarding is the act of transferring a message to another recipient address.  The change in recipient address is what distinguishes Forwarding from other types of relaying.  Relays using the SMTP protocol implement Forwarding by changing the address in the RCPT TO command.</text>
    <sha1>bd34622dff18d09231fddfccd264d76cb6547838</sha1>
  </revision>
  <revision>
    <id>1467</id>
    <parentid>1466</parentid>
    <timestamp>2008-12-21T17:22:27Z</timestamp>
    <contributor>
      <username>Macquigg</username>
      <id>2</id>
    </contributor>
    <minor/>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="360" xml:space="preserve">The definition for forwarding needs to be much more specific.  Here is a suggestion:

Forwarding is the act of transferring a message to another recipient address.  The change in recipient address is what distinguishes Forwarding from other types of relaying.  Relays using the SMTP protocol implement Forwarding by changing the address in the RCPT TO command.</text>
    <sha1>e7a7b41b30578e21d38dbf3f78e4316d255d5db6</sha1>
  </revision>
  <revision>
    <id>1468</id>
    <parentid>1467</parentid>
    <timestamp>2008-12-21T17:51:22Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>answer to David</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="616" xml:space="preserve">The definition for forwarding needs to be much more specific.  Here is a suggestion:

Forwarding is the act of transferring a message to another recipient address.  The change in recipient address is what distinguishes Forwarding from other types of relaying.  Relays using the SMTP protocol implement Forwarding by changing the address in the RCPT TO command.

:Forwarding is a fuzzy SMTP term, also because of how it is used in section 3.9 of RFC 5321. In addition, forwarding in ''our sense'' can be also done by a backup MX, without changing the envelope recipient. [[User:Ale|Ale]] 17:51, 21 December 2008 (GMT)</text>
    <sha1>8fd636062734ef29f48d1dbd02e341c01b79cb35</sha1>
  </revision>
  <revision>
    <id>1469</id>
    <parentid>1468</parentid>
    <timestamp>2008-12-21T20:01:13Z</timestamp>
    <contributor>
      <username>Macquigg</username>
      <id>2</id>
    </contributor>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2058" xml:space="preserve">The definition for forwarding needs to be much more specific.  Here is a suggestion:

Forwarding is the act of transferring a message to another recipient address.  The change in recipient address is what distinguishes Forwarding from other types of relaying.  Relays using the SMTP protocol implement Forwarding by changing the address in the RCPT TO command.

:Forwarding is a fuzzy SMTP term, also because of how it is used in section 3.9 of RFC 5321. In addition, forwarding in ''our sense'' can be also done by a backup MX, without changing the envelope recipient. [[User:Ale|Ale]] 17:51, 21 December 2008 (GMT)

We need to avoid the fuzzy terms, and get very specific about what we mean.  We already have a general term, relaying, which includes Forwarding and other actions, such as the MX relay you mentioned, open relays, and relays used as transmitters on behalf of domains wanting better deliverability.  Each of these forms of relaying has its own set of problems, and if we lump them all into "Forwarding", we won't be able to come up with a simple solution to the "forwarding problem".  For example, a backup MX must check periodically to see if the primary MX is up, and then transfer all the mail it has accumulated.

Conversely, there are things we will ask of Forwarders that we don't expect a backup MX to worry about, because there is a direct relationship between the backup MX and the primary MX.  They must be "tightly coupled", presumably under one management, so the authentication requirements we expect Forwarders to abide by don't apply.  If we ask all relays to set up authentication records, we will have  a huge problem with non-compliance.

The fundamental reason for the "forwarding problem" is the lack of a prior relationship between the Forwarder and the MDA (or downstream Agent).  We should limit our definition of Forwarding to just those situations that are likely to have this problem.  The narrower definition is also what I believe the SPF community wants. --[[User:Macquigg|Macquigg]] 20:01, 21 December 2008 (GMT)</text>
    <sha1>32d51c7cf0e952f29f3febea210c236958053426</sha1>
  </revision>
  <revision>
    <id>1470</id>
    <parentid>1469</parentid>
    <timestamp>2008-12-22T06:35:15Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Backup MXes</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="3310" xml:space="preserve">The definition for forwarding needs to be much more specific.  Here is a suggestion:

Forwarding is the act of transferring a message to another recipient address.  The change in recipient address is what distinguishes Forwarding from other types of relaying.  Relays using the SMTP protocol implement Forwarding by changing the address in the RCPT TO command.

:Forwarding is a fuzzy SMTP term, also because of how it is used in section 3.9 of RFC 5321. In addition, forwarding in ''our sense'' can be also done by a backup MX, without changing the envelope recipient. [[User:Ale|Ale]] 17:51, 21 December 2008 (GMT)

We need to avoid the fuzzy terms, and get very specific about what we mean.  We already have a general term, relaying, which includes Forwarding and other actions, such as the MX relay you mentioned, open relays, and relays used as transmitters on behalf of domains wanting better deliverability.  Each of these forms of relaying has its own set of problems, and if we lump them all into "Forwarding", we won't be able to come up with a simple solution to the "forwarding problem".  For example, a backup MX must check periodically to see if the primary MX is up, and then transfer all the mail it has accumulated.

Conversely, there are things we will ask of Forwarders that we don't expect a backup MX to worry about, because there is a direct relationship between the backup MX and the primary MX.  They must be "tightly coupled", presumably under one management, so the authentication requirements we expect Forwarders to abide by don't apply.  If we ask all relays to set up authentication records, we will have  a huge problem with non-compliance.

The fundamental reason for the "forwarding problem" is the lack of a prior relationship between the Forwarder and the MDA (or downstream Agent).  We should limit our definition of Forwarding to just those situations that are likely to have this problem.  The narrower definition is also what I believe the SPF community wants. --[[User:Macquigg|Macquigg]] 20:01, 21 December 2008 (GMT)

:I mostly agree with your analysis. However, there is one reason why it may be convenient to keep the definition fuzzy until the solution will have been analyzed more thoroughly.

:One reason why backup MXes need to couple with their primary is to learn what mail addresses they should reject. Traditionally, they don't have an explicit list of forwarding recipes, and deduce them from the MX records. By having an authentication record for each user they could actually create a list of valid addresses. Users preferences, e.g. about DNSBL checking, could be transferred by the same mechanisms that will have been built for explicit recipes --when it will have been built, that is.

:When spam wasn't a relevant problem, ESPs used to exchange or buy backup MX services from third parties. Helping to reinstate that possibility would be a plus. Backup MXes are not the primary concern of the FixForwarding solution, though. If we will realize that there is no piece of software or configuration setting that can be conveniently shared between the two problems, we will stop considering the second one. However, I don't think it's advantageous to blow that chance ''before'' realizing if that's the case. [[User:Ale|Ale]] 06:35, 22 December 2008 (GMT)</text>
    <sha1>d4df4646309017ea9040923f655d3b4830701e4d</sha1>
  </revision>
  <revision>
    <id>1472</id>
    <parentid>1470</parentid>
    <timestamp>2008-12-22T18:45:18Z</timestamp>
    <contributor>
      <username>Macquigg</username>
      <id>2</id>
    </contributor>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="3523" xml:space="preserve">The definition for forwarding needs to be much more specific.  Here is a suggestion:

Forwarding is the act of transferring a message to another recipient address.  The change in recipient address is what distinguishes Forwarding from other types of relaying.  Relays using the SMTP protocol implement Forwarding by changing the address in the RCPT TO command.

:Forwarding is a fuzzy SMTP term, also because of how it is used in section 3.9 of RFC 5321. In addition, forwarding in ''our sense'' can be also done by a backup MX, without changing the envelope recipient. [[User:Ale|Ale]] 17:51, 21 December 2008 (GMT)

We need to avoid the fuzzy terms, and get very specific about what we mean.  We already have a general term, relaying, which includes Forwarding and other actions, such as the MX relay you mentioned, open relays, and relays used as transmitters on behalf of domains wanting better deliverability.  Each of these forms of relaying has its own set of problems, and if we lump them all into "Forwarding", we won't be able to come up with a simple solution to the "forwarding problem".  For example, a backup MX must check periodically to see if the primary MX is up, and then transfer all the mail it has accumulated.

Conversely, there are things we will ask of Forwarders that we don't expect a backup MX to worry about, because there is a direct relationship between the backup MX and the primary MX.  They must be "tightly coupled", presumably under one management, so the authentication requirements we expect Forwarders to abide by don't apply.  If we ask all relays to set up authentication records, we will have  a huge problem with non-compliance.

The fundamental reason for the "forwarding problem" is the lack of a prior relationship between the Forwarder and the MDA (or downstream Agent).  We should limit our definition of Forwarding to just those situations that are likely to have this problem.  The narrower definition is also what I believe the SPF community wants. --[[User:Macquigg|Macquigg]] 20:01, 21 December 2008 (GMT)

:I mostly agree with your analysis. However, there is one reason why it may be convenient to keep the definition fuzzy until the solution will have been analyzed more thoroughly.

:One reason why backup MXes need to couple with their primary is to learn what mail addresses they should reject. Traditionally, they don't have an explicit list of forwarding recipes, and deduce them from the MX records. By having an authentication record for each user they could actually create a list of valid addresses. Users preferences, e.g. about DNSBL checking, could be transferred by the same mechanisms that will have been built for explicit recipes --when it will have been built, that is.

:When spam wasn't a relevant problem, ESPs used to exchange or buy backup MX services from third parties. Helping to reinstate that possibility would be a plus. Backup MXes are not the primary concern of the FixForwarding solution, though. If we will realize that there is no piece of software or configuration setting that can be conveniently shared between the two problems, we will stop considering the second one. However, I don't think it's advantageous to blow that chance ''before'' realizing if that's the case. [[User:Ale|Ale]] 06:35, 22 December 2008 (GMT)

OK, we'll keep the definitions fuzzy on the main pages, and I will try to clarify each time I am sssuming a more specific definition.  When I capitalize a word like Forwarder, it means the definition is special.</text>
    <sha1>62e2a26496a136e1a9863b96cc3f4feace000136</sha1>
  </revision>
  <revision>
    <id>1473</id>
    <parentid>1472</parentid>
    <timestamp>2008-12-22T18:45:49Z</timestamp>
    <contributor>
      <username>Macquigg</username>
      <id>2</id>
    </contributor>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="3581" xml:space="preserve">The definition for forwarding needs to be much more specific.  Here is a suggestion:

Forwarding is the act of transferring a message to another recipient address.  The change in recipient address is what distinguishes Forwarding from other types of relaying.  Relays using the SMTP protocol implement Forwarding by changing the address in the RCPT TO command.

:Forwarding is a fuzzy SMTP term, also because of how it is used in section 3.9 of RFC 5321. In addition, forwarding in ''our sense'' can be also done by a backup MX, without changing the envelope recipient. [[User:Ale|Ale]] 17:51, 21 December 2008 (GMT)

We need to avoid the fuzzy terms, and get very specific about what we mean.  We already have a general term, relaying, which includes Forwarding and other actions, such as the MX relay you mentioned, open relays, and relays used as transmitters on behalf of domains wanting better deliverability.  Each of these forms of relaying has its own set of problems, and if we lump them all into "Forwarding", we won't be able to come up with a simple solution to the "forwarding problem".  For example, a backup MX must check periodically to see if the primary MX is up, and then transfer all the mail it has accumulated.

Conversely, there are things we will ask of Forwarders that we don't expect a backup MX to worry about, because there is a direct relationship between the backup MX and the primary MX.  They must be "tightly coupled", presumably under one management, so the authentication requirements we expect Forwarders to abide by don't apply.  If we ask all relays to set up authentication records, we will have  a huge problem with non-compliance.

The fundamental reason for the "forwarding problem" is the lack of a prior relationship between the Forwarder and the MDA (or downstream Agent).  We should limit our definition of Forwarding to just those situations that are likely to have this problem.  The narrower definition is also what I believe the SPF community wants. --[[User:Macquigg|Macquigg]] 20:01, 21 December 2008 (GMT)

:I mostly agree with your analysis. However, there is one reason why it may be convenient to keep the definition fuzzy until the solution will have been analyzed more thoroughly.

:One reason why backup MXes need to couple with their primary is to learn what mail addresses they should reject. Traditionally, they don't have an explicit list of forwarding recipes, and deduce them from the MX records. By having an authentication record for each user they could actually create a list of valid addresses. Users preferences, e.g. about DNSBL checking, could be transferred by the same mechanisms that will have been built for explicit recipes --when it will have been built, that is.

:When spam wasn't a relevant problem, ESPs used to exchange or buy backup MX services from third parties. Helping to reinstate that possibility would be a plus. Backup MXes are not the primary concern of the FixForwarding solution, though. If we will realize that there is no piece of software or configuration setting that can be conveniently shared between the two problems, we will stop considering the second one. However, I don't think it's advantageous to blow that chance ''before'' realizing if that's the case. [[User:Ale|Ale]] 06:35, 22 December 2008 (GMT)

OK, we'll keep the definitions fuzzy on the main pages, and I will try to clarify each time I am sssuming a more specific definition.  When I capitalize a word like Forwarder, it means the definition is special.--[[User:Macquigg|Macquigg]] 18:45, 22 December 2008 (GMT)</text>
    <sha1>13b685b51b0dfc0d8d5e6e32560173e22170578b</sha1>
  </revision>
</page>
<page arvcontinue="20081206153830|1455">
  <title>Talk:solution proposed</title>
  <ns>1</ns>
  <id>19</id>
  <revision>
    <id>1471</id>
    <timestamp>2008-12-22T18:43:25Z</timestamp>
    <contributor>
      <username>Macquigg</username>
      <id>2</id>
    </contributor>
    <comment>simpler solution</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="3245" xml:space="preserve">The forwarding agreement should be simple - an MDA should accept all mail transmitted by this domain to that recipient, and not get involved in spam reporting.  The assumptions on forwarded mail are that the Forwarder has already performed spam filtering and other Border functions per the recipient's instructions.  The recipient should report spam directly to the Forwarder, not to the MDA.

Likewise, if there is a problem separating one mailing list from another, it should be resolved between the recipient and the Forwarder, and not involve the MDA.  We need to keep the forwarding agreement simple, or there will be no universal solution.

Another simplifying assumption is that the MDA will not re-forward any mail (no chain forwarding).  There is no good reason for re-forwarding, and it can only lead to confusion in reporting spam and handling bounces.  Recipients should understand (and Forwarders should make sure they understand) how forwarding works, and why chain forwarding is unnecessary and unreliable.

MDAs that allow domain-level white listing are already set up to allow forwarding.  No special software is required.  Note, however, that the whitelisted domain must be that of the Forwarder, not the domain in the Return Address or in any address in the message headers.

The mechanism for setting up a forwarding agreement should not require any new protocols or even extensions of existing protocols.  It should be easily automated, but should also work for small domains that have no such automation.  A standard request form, from postmaster to postmaster, should be sufficient.  For example:

=== Forwarding Request ===

   To:       postmaster@mda.com
   From:     postmaster@forwarder.com
   Subject:  Forwarding Request 8xPk7e

   Forwarding Domain: &lt;forwarder.com&gt;
   Transmitters: [235.66.107.32-5]
   Recipient Address: &lt;recipient@mda.com&gt;

   This recipient has requested that we forward mail to your domain.  You should
   verify this with your recipient.

   To accept this request, return this message with the subject line unaltered.  To
   refuse this request, just ignore it.  To discontinue forwarding at any time in
   the future, send an SMTP REJECT in reply to the RCPT TO: command.  This will
   happen normally when the recipient account is removed from your domain.

   Please whitelist mail forwarded from our domain to this recipient.  This mail
   has been processed per the recipient's instructions, and needs no further
   filtering.

   Do not report as spam any mail forwarded under this arrangement.  The recipient
   will report spam directly to us at &lt;spam_report@forwarder.com&gt;.

   Thank you for your time and attention.

Notice the following features:
1) The subject line is standardized for automated processing - two keywords and an authentication code.  The code may be used to verify that a reply is valid.
2) The first three lines of the message body are also set up for automated processing.  The information is complete and unambiguous, yet still human readable.
3) The remainder of the message has simple, complete, and unambiguous instructions for someone who might be seeing this kind of request for the first time.
--[[User:Macquigg|Macquigg]] 18:43, 22 December 2008 (GMT)</text>
    <sha1>5c0b77e6a1ca59bb786e186bd2ad896f28bac66e</sha1>
  </revision>
  <revision>
    <id>1474</id>
    <parentid>1471</parentid>
    <timestamp>2008-12-23T15:25:36Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Reasons to ''complicate'' the solution</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6952" xml:space="preserve">The forwarding agreement should be simple - an MDA should accept all mail transmitted by this domain to that recipient, and not get involved in spam reporting.  The assumptions on forwarded mail are that the Forwarder has already performed spam filtering and other Border functions per the recipient's instructions.  The recipient should report spam directly to the Forwarder, not to the MDA.

Likewise, if there is a problem separating one mailing list from another, it should be resolved between the recipient and the Forwarder, and not involve the MDA.  We need to keep the forwarding agreement simple, or there will be no universal solution.

Another simplifying assumption is that the MDA will not re-forward any mail (no chain forwarding).  There is no good reason for re-forwarding, and it can only lead to confusion in reporting spam and handling bounces.  Recipients should understand (and Forwarders should make sure they understand) how forwarding works, and why chain forwarding is unnecessary and unreliable.

MDAs that allow domain-level white listing are already set up to allow forwarding.  No special software is required.  Note, however, that the whitelisted domain must be that of the Forwarder, not the domain in the Return Address or in any address in the message headers.

The mechanism for setting up a forwarding agreement should not require any new protocols or even extensions of existing protocols.  It should be easily automated, but should also work for small domains that have no such automation.  A standard request form, from postmaster to postmaster, should be sufficient.  For example:

=== Forwarding Request ===

   To:       postmaster@mda.com
   From:     postmaster@forwarder.com
   Subject:  Forwarding Request 8xPk7e

   Forwarding Domain: &lt;forwarder.com&gt;
   Transmitters: [235.66.107.32-5]
   Recipient Address: &lt;recipient@mda.com&gt;

   This recipient has requested that we forward mail to your domain.  You should
   verify this with your recipient.

   To accept this request, return this message with the subject line unaltered.  To
   refuse this request, just ignore it.  To discontinue forwarding at any time in
   the future, send an SMTP REJECT in reply to the RCPT TO: command.  This will
   happen normally when the recipient account is removed from your domain.

   Please whitelist mail forwarded from our domain to this recipient.  This mail
   has been processed per the recipient's instructions, and needs no further
   filtering.

   Do not report as spam any mail forwarded under this arrangement.  The recipient
   will report spam directly to us at &lt;spam_report@forwarder.com&gt;.

   Thank you for your time and attention.

Notice the following features:
1) The subject line is standardized for automated processing - two keywords and an authentication code.  The code may be used to verify that a reply is valid.
2) The first three lines of the message body are also set up for automated processing.  The information is complete and unambiguous, yet still human readable.
3) The remainder of the message has simple, complete, and unambiguous instructions for someone who might be seeing this kind of request for the first time.
--[[User:Macquigg|Macquigg]] 18:43, 22 December 2008 (GMT)

== Reasons to ''complicate'' the solution ==
The simpler the solution, the tougher. Why do more than is strictly necessary?

=== Reporting spam ===
Users at MDA.com, the broad-sense ''mail delivery agent'' exemplified above, have no formal method to distinguish forwarded messages from the rest of their mail. What tool do they use to report spam? Spam reporting is slowly getting standardized. However, currently only its format has been the subject of a proposed draft; see [[wp:Feedback Loop (email)]].

A ''Report Spam'' button displayed in the context of a message forwarded according to a subscription is ambiguous, since it may be used to either unsubscribe from the mailing list, or signal to the list owner that the message displayed is spam. Users would get the second meaning only if the button is list-specific, which implies the ability to automatically distinguish which list of which forwarder a specific message belongs to. (The latter information should be carried by an ''Authentication-Results'' or similar header, since ''Received'' headers are difficult to parse.)

On the other hand, even if it were clear where spam reports should be addressed, MUAs may prefer not to get in touch with unknown hosts for security reasons, as it happens for ''List-Unsubscribe'' of RFC 2369. Hence, it seems more practicable to uniformly direct all spam reports to the server that is directly responsible for delivering to the given mailbox.

=== Chain forwarding ===
Users choose a mailbox (web, IMAP, POP3) server based on a number of criteria, including convenience, availability, costs. However, they may also want to keep using email addresses at other domains for a variety of reasons, e.g. because it is the place where they work, or they have digital certificates or signed keys that include a given address, or they just gave the address to so many people and places that it will take some time to change it. The only solution in those cases is forwarding, at least temporarily.

=== Users preferences ===
DNSBL filtering may be considered unreliable without proper whitelisting, since there are large free falling ISPs that don't care being blacklisted, and are still very popular in their area. Some people opt for never publishing their email address, that way they are never targeted by spammers. They would rather skip DNSBL filtering altogether, unless whitelisting were available.

In general, reputation services are based on people judgment. Imposing the choice of a fixed set of reputation services can be a characterizing feature of certain ESPs, but it makes no sense for forwarding. Even if the exemplified procedure mentions processing ''per the recipient's instructions'', it is not clear where those instructions are stored and how the recipient can change them.

=== Automating the process ===
The exemplified request avoids the only SMTP extension formally required by the [[solution proposed]] by replacing the ''EHLO advertised URL'' with, e.g., ''postmaster@MDA.com''.

The advantage of SMTP transport is that an handshake can be carried out even without software support. Good point. SOAP can use SMTP transport too; however, that's less readable.

A one-way handshake is certainly simpler than a three-way one. It is also less customizable. Postmaster@forwarder.com will never know whether a request has been refused (and why) or it is just taking more time to be accepted. A new agreement will be needed if MDA.com has to change its transmitters' IPs.


Finally, I think that the advantage of attempting a standardization is that compliant software can be written. I would be available to small and large domains alike.

[[User:Ale|Ale]] 15:25, 23 December 2008 (GMT)</text>
    <sha1>4430a036a6c0030db67a8774491926c30ec7cd57</sha1>
  </revision>
  <revision>
    <id>1476</id>
    <parentid>1474</parentid>
    <timestamp>2008-12-24T20:23:05Z</timestamp>
    <contributor>
      <username>Macquigg</username>
      <id>2</id>
    </contributor>
    <comment>Forwarding Setup Confirmation</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="11073" xml:space="preserve">The forwarding agreement should be simple - an MDA should accept all mail transmitted by this domain to that recipient, and not get involved in spam reporting.  The assumptions on forwarded mail are that the Forwarder has already performed spam filtering and other Border functions per the recipient's instructions.  The recipient should report spam directly to the Forwarder, not to the MDA.

Likewise, if there is a problem separating one mailing list from another, it should be resolved between the recipient and the Forwarder, and not involve the MDA.  We need to keep the forwarding agreement simple, or there will be no universal solution.

Another simplifying assumption is that the MDA will not re-forward any mail (no chain forwarding).  There is no good reason for re-forwarding, and it can only lead to confusion in reporting spam and handling bounces.  Recipients should understand (and Forwarders should make sure they understand) how forwarding works, and why chain forwarding is unnecessary and unreliable.

MDAs that allow domain-level white listing are already set up to allow forwarding.  No special software is required.  Note, however, that the whitelisted domain must be that of the Forwarder, not the domain in the Return Address or in any address in the message headers.

The mechanism for setting up a forwarding agreement should not require any new protocols or even extensions of existing protocols.  It should be easily automated, but should also work for small domains that have no such automation.  A standard request form, from postmaster to postmaster, should be sufficient.  For example:

== Forwarding Request ==

   To:       postmaster@mda.com
   From:     postmaster@forwarder.com
   Subject:  Forwarding Request 8xPk7e

   Forwarding Domain: &lt;forwarder.com&gt;
   Transmitters: [235.66.107.32-5]
   Recipient Address: &lt;recipient@mda.com&gt;

   This recipient has requested that we forward mail to your domain.  You should
   verify this with your recipient.

   To accept this request, return this message with the subject line unaltered.  To
   refuse this request, just ignore it.  To discontinue forwarding at any time in
   the future, send an SMTP REJECT in reply to the RCPT TO: command.  This will
   happen normally when the recipient account is removed from your domain.

   Please whitelist mail forwarded from our domain to this recipient.  This mail
   has been processed per the recipient's instructions, and needs no further
   filtering.

   Do not report as spam any mail forwarded under this arrangement.  The recipient
   will report spam directly to us at &lt;spamreports@forwarder.com&gt;.

   Thank you for your time and attention.

Notice the following features:
1) The subject line is standardized for automated processing - two keywords and an authentication code.  The code may be used to verify that a reply is valid.
2) The first three lines of the message body are also set up for automated processing.  The information is complete and unambiguous, yet still human readable.
3) The remainder of the message has simple, complete, and unambiguous instructions for someone who might be seeing this kind of request for the first time.
--[[User:Macquigg|Macquigg]] 18:43, 22 December 2008 (GMT)

== Reasons to ''complicate'' the solution ==
The simpler the solution, the tougher. Why do more than is strictly necessary?

=== Reporting spam ===
Users at MDA.com, the broad-sense ''mail delivery agent'' exemplified above, have no formal method to distinguish forwarded messages from the rest of their mail. What tool do they use to report spam? Spam reporting is slowly getting standardized. However, currently only its format has been the subject of a proposed draft; see [[wp:Feedback Loop (email)]].

A ''Report Spam'' button displayed in the context of a message forwarded according to a subscription is ambiguous, since it may be used to either unsubscribe from the mailing list, or signal to the list owner that the message displayed is spam. Users would get the second meaning only if the button is list-specific, which implies the ability to automatically distinguish which list of which forwarder a specific message belongs to. (The latter information should be carried by an ''Authentication-Results'' or similar header, since ''Received'' headers are difficult to parse.)

On the other hand, even if it were clear where spam reports should be addressed, MUAs may prefer not to get in touch with unknown hosts for security reasons, as it happens for ''List-Unsubscribe'' of RFC 2369. Hence, it seems more practicable to uniformly direct all spam reports to the server that is directly responsible for delivering to the given mailbox.

: I agree that the current confusion over spam reporting is unacceptable.  I would not expect the MDA to handle all reports, however.  This puts too much burden on services that will not handle the reports properly.  I use yahoo.com for my MDA, and I certainly don't want them involved in processing spam that came through my Receiver, box67.com. --[[User:Macquigg|Macquigg]] 20:23, 24 December 2008 (GMT)

=== Chain forwarding ===
Users choose a mailbox (web, IMAP, POP3) server based on a number of criteria, including convenience, availability, costs. However, they may also want to keep using email addresses at other domains for a variety of reasons, e.g. because it is the place where they work, or they have digital certificates or signed keys that include a given address, or they just gave the address to so many people and places that it will take some time to change it. The only solution in those cases is forwarding, at least temporarily.

: Forwarding is good.  Chain forwarding should be discouraged.  It serves no good purpose, and vastly complicates authentication, spam reporting, etc. --[[User:Macquigg|Macquigg]] 20:23, 24 December 2008 (GMT)

=== Users preferences ===
DNSBL filtering may be considered unreliable without proper whitelisting, since there are large free falling ISPs that don't care being blacklisted, and are still very popular in their area. Some people opt for never publishing their email address, that way they are never targeted by spammers. They would rather skip DNSBL filtering altogether, unless whitelisting were available.

In general, reputation services are based on people judgment. Imposing the choice of a fixed set of reputation services can be a characterizing feature of certain ESPs, but it makes no sense for forwarding. Even if the exemplified procedure mentions processing ''per the recipient's instructions'', it is not clear where those instructions are stored and how the recipient can change them.

: That needs to be made clear by the Forwarder at the time the Recipient initiates forwarding.  Blacklists, spam filtering, reputation assessment, and other Border defense functions should be done by the Border MTA.  The MDA should handle only functions related to delivery.  Things get very messy otherwise.  --[[User:Macquigg|Macquigg]] 20:23, 24 December 2008 (GMT) 

=== Automating the process ===
The exemplified request avoids the only SMTP extension formally required by the [[solution proposed]] by replacing the ''EHLO advertised URL'' with, e.g., ''postmaster@MDA.com''.

The advantage of SMTP transport is that an handshake can be carried out even without software support. Good point. SOAP can use SMTP transport too; however, that's less readable.

A one-way handshake is certainly simpler than a three-way one. It is also less customizable. Postmaster@forwarder.com will never know whether a request has been refused (and why) or it is just taking more time to be accepted. A new agreement will be needed if MDA.com has to change its transmitters' IPs.

Finally, I think that the advantage of attempting a standardization is that compliant software can be written. I would be available to small and large domains alike.

[[User:Ale|Ale]] 15:25, 23 December 2008 (GMT)

: I will support your efforts to get an SMTP extension.  Meanwhile, we have to do the best we can with what we've got, even if it is only an interim solution.  --[[User:Macquigg|Macquigg]] 20:23, 24 December 2008 (GMT)

== Forwarding Setup Confirmation == 

   To:      alice@forwarder.com
   From:    postmaster@forwarder.com
   Subject: Forwarding Request 8xPk7e

   Incoming address:      alice@forwarder.com
   Destination address:   alice@mda.com
   Forwarding setup page: http://forwarder.com/ForwardingSetup
      Options selected:     A1 B3 C2 D5 WL
      Alternate address:    alice-alternate@mda.com

   To confirm this request, reply to this message with the subject line unaltered.
   To cancel this request, just ignore this message.  To avoid confusion and
   possible rejection of this request, make sure proper arrangements have been
   made at the destination address.  Do this now, before sending the reply to this
   message.

   Failure to make arrangements at the destination may result in a surprising and
   sudden cancellation of forwarding sometime in the future.  See below for
   details.

   Upon receipt of this confirmation and acceptance of a "forwarding agreement" by
   the destination postmaster, we will forward mail as specified above.  You can
   check the status of this forwarding agreement at your forwarding setup page.
   You can also initiate forwarding with no agreement by the destination domain,
   but see below for warnings.

   We will send you a reminder once per month as long as your forwarding
   arrangement is active.

   ****** Details on setting up forwarding at a destination domain ******

   The biggest problem in forwarding is erroneous spam reports against the
   Forwarder (us).  If that happens, we will immediately cancel the forwarding
   arranagement, and notify you at your alternate address above.

   Forwarded mail should go directly to its final destination, and not be
   forwarded again.  "Chain forwarding" almost always leads to problems such as
   authentication failures, erroneous spam reports, etc.

   Spam filtering, blacklisting, and other Border defense functions should be done
   just once, at the server which first receives the mail (the "Border MTA").  We
   will perform these functions to the best of our ability, following the
   instructions on your Recipient Options form http://forwarder.com/RecipientOptions.

   Please whitelist mail forwarded by our domain to your destination address. Do
   not use the destination domain's spam reporting process.  Report spam directly
   to us at &lt;spamreports@forwarder.com&gt;.  See http://forwarder.com/SpamReports for
   details.

   If your destination domain does not provide whitelisting, or is not able to
   properly authenticate our transmitters, an alternative is to set up a new
   account with a private name just to store your forwarded mail. Use an address
   that spammers cannot guess, like alice85770.  For more recommendations, and a
   list of services that support forwarding, see
   http://forwarder.com/ServiceProviders.
--[[User:Macquigg|Macquigg]] 20:23, 24 December 2008 (GMT)</text>
    <sha1>77a7e46a38c1c1bcf516723c24b4750501243e74</sha1>
  </revision>
</page>
<page arvcontinue="20081206153830|1455">
  <title>forwarding agreement</title>
  <ns>0</ns>
  <id>11</id>
  <revision>
    <id>1477</id>
    <parentid>1454</parentid>
    <timestamp>2008-12-27T12:52:52Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* URLs */ link to each URL's page</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6551" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and password pair, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''.

The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for logging in. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. Possible categories are
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, and
* backup MX.

The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the password changing URL and obtain a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP pages under https transport. The certificate and its signing authority can be taken into account when deciding to grant the agreement.

Thus far, we have defined the following ones:
* the [[EHLO advertised URL]],
* the [[password changing URL]], and
* the [[policy negotiation URL]] at the sender's.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for the given recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail address that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. As that is part of the forwarding recipe, the termination record may optionally be kept for a certain time, in order to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SMTP AUTH mechanism being used to log in, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>9ceaba8651a6219018d7bf6bac3e4adabdd1c01e</sha1>
  </revision>
  <revision>
    <id>1478</id>
    <parentid>1477</parentid>
    <timestamp>2008-12-27T12:54:53Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Data fields */ convert paragraphs to subsections</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6626" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and password pair, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''.

=== agreement-ID ===
The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for logging in. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

=== forwarder-ID ===
The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

=== category ===
The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. Possible categories are
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, and
* backup MX.

=== user-ID ===
The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the password changing URL and obtain a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP pages under https transport. The certificate and its signing authority can be taken into account when deciding to grant the agreement.

Thus far, we have defined the following ones:
* the [[EHLO advertised URL]],
* the [[password changing URL]], and
* the [[policy negotiation URL]] at the sender's.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for the given recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail address that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. As that is part of the forwarding recipe, the termination record may optionally be kept for a certain time, in order to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SMTP AUTH mechanism being used to log in, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>20dfb42276402d78923207be1cba07278ede2df5</sha1>
  </revision>
  <revision>
    <id>1484</id>
    <parentid>1478</parentid>
    <timestamp>2008-12-27T17:03:58Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* URLs */ note examples of protocols using soap</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6720" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and password pair, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''.

=== agreement-ID ===
The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for logging in. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

=== forwarder-ID ===
The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

=== category ===
The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. Possible categories are
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, and
* backup MX.

=== user-ID ===
The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the password changing URL and obtain a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP request/response pages under HTTPS transport. The certificate and its signing authority can be taken into account when deciding to grant the agreement. Experience published about NETCONF can be used as a guideline, see RFC 5381.

Thus far, we have defined the following URLs:
* the [[EHLO advertised URL]],
* the [[password changing URL]], and
* the [[policy negotiation URL]] at the sender's.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for the given recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail address that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. As that is part of the forwarding recipe, the termination record may optionally be kept for a certain time, in order to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SMTP AUTH mechanism being used to log in, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>1aa5dab48f0f72220293df0b44e899bd454a55de</sha1>
  </revision>
  <revision>
    <id>1486</id>
    <parentid>1484</parentid>
    <timestamp>2008-12-27T19:10:34Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* URLs */ FBL must be set in the 3rd URL</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6715" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and password pair, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''.

=== agreement-ID ===
The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for logging in. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

=== forwarder-ID ===
The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

=== category ===
The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. Possible categories are
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, and
* backup MX.

=== user-ID ===
The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the password changing URL and obtain a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP request/response pages under HTTPS transport. The certificate and its signing authority can be taken into account when deciding to grant the agreement. Experience published about NETCONF can be used as a guideline, see RFC 5381.

Thus far, we have defined the following URLs:
* the [[EHLO advertised URL]],
* the [[password/FBL URL]], and
* the [[policy negotiation URL]] at the sender's.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for the given recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail address that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. As that is part of the forwarding recipe, the termination record may optionally be kept for a certain time, in order to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SMTP AUTH mechanism being used to log in, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>16f8c0c7415b3339d39c85e6cdce2564cbd86cec</sha1>
  </revision>
  <revision>
    <id>1487</id>
    <parentid>1486</parentid>
    <timestamp>2008-12-27T19:17:08Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* URLs */ refine transport considerations</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7021" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and password pair, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''.

=== agreement-ID ===
The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for logging in. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

=== forwarder-ID ===
The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

=== category ===
The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. Possible categories are
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, and
* backup MX.

=== user-ID ===
The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the password changing URL and obtain a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP request/response pages under HTTPS transport. An advantage of SOAP is that it avoids having to specify any encoding, multiple lines syntax, and similar kind of stuff; experience published about NETCONF can be used as a guideline, see RFC 5381. HTTPS as a transport allows secure password exchange; in addition, the certificate and its signing authority can be taken into account when deciding to grant the agreement (but see also [[policy negotiation URL#Credentials and cryptographic support|Credentials and cryptographic support]].)

Thus far, we have defined the following URLs:
* the [[EHLO advertised URL]],
* the [[password/FBL URL]], and
* the [[policy negotiation URL]] at the sender's.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for the given recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail address that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. As that is part of the forwarding recipe, the termination record may optionally be kept for a certain time, in order to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SMTP AUTH mechanism being used to log in, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>ff1fc855295a6c3247785e20ebce9d983a3d0b60</sha1>
  </revision>
  <revision>
    <id>1488</id>
    <parentid>1487</parentid>
    <timestamp>2008-12-28T10:30:58Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* URLs */ rename password/FBL =&gt; completion</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7019" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and password pair, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''.

=== agreement-ID ===
The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for logging in. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

=== forwarder-ID ===
The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

=== category ===
The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. Possible categories are
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, and
* backup MX.

=== user-ID ===
The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the password changing URL and obtain a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP request/response pages under HTTPS transport. An advantage of SOAP is that it avoids having to specify any encoding, multiple lines syntax, and similar kind of stuff; experience published about NETCONF can be used as a guideline, see RFC 5381. HTTPS as a transport allows secure password exchange; in addition, the certificate and its signing authority can be taken into account when deciding to grant the agreement (but see also [[policy negotiation URL#Credentials and cryptographic support|Credentials and cryptographic support]].)

Thus far, we have defined the following URLs:
* the [[EHLO advertised URL]],
* the [[completion URL]], and
* the [[policy negotiation URL]] at the sender's.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for the given recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail address that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. As that is part of the forwarding recipe, the termination record may optionally be kept for a certain time, in order to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SMTP AUTH mechanism being used to log in, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>4dc306c22eec042e7e62b30956ff606602c4d4ce</sha1>
  </revision>
  <revision>
    <id>1497</id>
    <parentid>1488</parentid>
    <timestamp>2008-12-28T12:44:05Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* category */ explain static vs dynamic recipes</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7424" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and password pair, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''.

=== agreement-ID ===
The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for logging in. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

=== forwarder-ID ===
The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

=== category ===
The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. Possible categories are
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, and
* backup MX.

Sometimes static recipes can be edited using web forms or other remote mechanisms. The key difference is that static recipes allow a single user with enough permissions to edit multiple addresses at once, e.g. by providing a comma separated list. Dynamic recipes allow to independently add/delete single addresses without even letting the relevant user know whether there are more addresses on the list.

=== user-ID ===
The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the password changing URL and obtain a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP request/response pages under HTTPS transport. An advantage of SOAP is that it avoids having to specify any encoding, multiple lines syntax, and similar kind of stuff; experience published about NETCONF can be used as a guideline, see RFC 5381. HTTPS as a transport allows secure password exchange; in addition, the certificate and its signing authority can be taken into account when deciding to grant the agreement (but see also [[policy negotiation URL#Credentials and cryptographic support|Credentials and cryptographic support]].)

Thus far, we have defined the following URLs:
* the [[EHLO advertised URL]],
* the [[completion URL]], and
* the [[policy negotiation URL]] at the sender's.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for the given recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail address that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. As that is part of the forwarding recipe, the termination record may optionally be kept for a certain time, in order to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SMTP AUTH mechanism being used to log in, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>ea777ff73c681377b340947b1bbe198a0203b001</sha1>
  </revision>
</page>
<page arvcontinue="20081206153830|1455">
  <title>EHLO advertised URL</title>
  <ns>0</ns>
  <id>20</id>
  <revision>
    <id>1479</id>
    <timestamp>2008-12-27T13:59:30Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>new page</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4020" xml:space="preserve">The '''EHLO advertised URL''' receives ''forwarding requests''; that is, requests for establishing a [[forwarding agreement]]. The server of the URL is an MTA ready to grant such agreements. The client is an MTA configured with a [[forwarding recipe]], that is willing to relay related messages under an agreement. As its name says, this URL is advertised by the server in its EHLO response.

The client is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Client and server are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
Visiting this URL constitutes the first of the three steps provided for setting up a forwarding agreement. The URL itself may change as needed, since it is only used once for each request. The clients posts (or ''sends'', if using SMTP transport) the essential data that defines the agreement:

* The ''recipe-ID''; that is, the key or authentication code of the agreement, as known by the client.
* Optionally, the ''recipe name''; this should be the incoming address at the client's in the case of static forwarding, or the newsletter or mailing list name. It should be human readable and defaults to the recipe-ID.
* The ''recipient address(es)''; the target addresses at the server's. The server will transform these into the agreement's [[forwarding agreement#user-ID|user-ID]], according to its internal data structures.
* The agreement's ''category'', one of the [[forwarding agreement#category|types defined]].
* The [[policy negotiation URL]], where the server will in turn pay a visit.
* Optionally, the ''Forwarder-ID''; this is the identity of the client as known by the server, in case the client has already entered into an agreement with the same server.
* Optionally, any evidence that may be relevant. For example, the IP address and GMT date of the user's opt-in.

The tentative list above is meant to comprise all the data to fully describe the forwarder's intentions.

The recipe-ID will be used by the server when it will in turn pay a visit to the supplied policy negotiation URL. By contrast, the ''recipe name'' is what will be visible to users.

The client is not authenticated at this stage. If a ''Forwarder-ID'' is supplied, the server should verify that the policy negotiation URL coincides with the one already stored for that ID. If not, it must discard the supplied ''Forwarder-ID''.

The server should carry out any verification that it wishes. If supplied evidence includes IP addresses that the server can verify, it should do so before they possibly change and before relevant log files are obliterated. Notice that, except for evidence, no IP addresses are involved.

=== Server response ===
The server may take several paths. When the client is known and trustworthy, the server may visit the policy URL on the fly and respond to the requester process accordingly. Likewise, if the server can estimate that the agreement is likely to be granted within a few hours, it should say so. That information is needed by the client in order to decide how to queue the message at hand.

If any verification fails, the server may reject the request and let the client try again with a better request. If the request mentions an agreement that has already been established, the server should just signal that this is a spoof retrial.

If the server requires human intervention, or other lengthy process that may eventually result in negotiating a policy and granting the agreement, it should signal so. In this case the client marks the recipe as having an agreement underway, and continues to relay as usual meanwhile. It is the server responsibility to eventually visit the policy negotiation URL, possibly for the sole purpose of canceling the pending request.

Notice that it may be convenient for the server to grant an agreement to a known spammer for the sole purpose of rejecting any mail identified that way.</text>
    <sha1>b172d3a808048b15be321ef202f279898e05167e</sha1>
  </revision>
  <revision>
    <id>1480</id>
    <parentid>1479</parentid>
    <timestamp>2008-12-27T15:21:33Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Semantics */ Forwarder-ID may be a hint</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4156" xml:space="preserve">The '''EHLO advertised URL''' receives ''forwarding requests''; that is, requests for establishing a [[forwarding agreement]]. The server of the URL is an MTA ready to grant such agreements. The client is an MTA configured with a [[forwarding recipe]], that is willing to relay related messages under an agreement. As its name says, this URL is advertised by the server in its EHLO response.

The client is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Client and server are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
Visiting this URL constitutes the first of the three steps provided for setting up a forwarding agreement. The URL itself may change as needed, since it is only used once for each request. The clients posts (or ''sends'', if using SMTP transport) the essential data that defines the agreement:

* The ''recipe-ID''; that is, the key or authentication code of the agreement, as known by the client.
* Optionally, the ''recipe name''; this should be the incoming address at the client's in the case of static forwarding, or the newsletter or mailing list name. It should be human readable and defaults to the recipe-ID.
* The ''recipient address(es)''; the target addresses at the server's. The server will transform these into the agreement's [[forwarding agreement#user-ID|user-ID]], according to its internal data structures.
* The agreement's ''category'', one of the [[forwarding agreement#category|types defined]].
* The [[policy negotiation URL]], where the server will in turn pay a visit.
* Optionally, the ''Forwarder-ID''; this is the identity of the client as known by the server, in case the client has already entered into an agreement with the same server.
* Optionally, any evidence that may be relevant. For example, the IP address and GMT date of the user's opt-in.

The tentative list above is meant to comprise all the data to fully describe the forwarder's intentions.

The recipe-ID will be used by the server when it will in turn pay a visit to the supplied policy negotiation URL. By contrast, the ''recipe name'' is what will be visible to users.

The client is not authenticated at this stage. If a ''Forwarder-ID'' is supplied, the server should verify that the policy negotiation URL coincides with the one already stored for that ID. If not recognized, the server must not use the supplied ''Forwarder-ID'' for making decisions, but may use it as a hint to synthesize the content of the corresponding field of the agreement.

The server should carry out any verification that it wishes. If supplied evidence includes IP addresses that the server can verify, it should do so before they possibly change and before relevant log files are obliterated. Notice that, except for evidence, no IP addresses are involved.

=== Server response ===
The server may take several paths. When the client is known and trustworthy, the server may visit the policy URL on the fly and respond to the requester process accordingly. Likewise, if the server can estimate that the agreement is likely to be granted within a few hours, it should say so. That information is needed by the client in order to decide how to queue the message at hand.

If any verification fails, the server may reject the request and let the client try again with a better request. If the request mentions an agreement that has already been established, the server should just signal that this is a spoof retrial.

If the server requires human intervention, or other lengthy process that may eventually result in negotiating a policy and granting the agreement, it should signal so. In this case the client marks the recipe as having an agreement underway, and continues to relay as usual meanwhile. It is the server responsibility to eventually visit the policy negotiation URL, possibly for the sole purpose of canceling the pending request.

Notice that it may be convenient for the server to grant an agreement to a known spammer for the sole purpose of rejecting any mail identified that way.</text>
    <sha1>fbfc1c62ff6146ebc81b488a15e8cd3da341c706</sha1>
  </revision>
  <revision>
    <id>1481</id>
    <parentid>1480</parentid>
    <timestamp>2008-12-27T16:02:49Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Semantics */ recipe name not optional</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4183" xml:space="preserve">The '''EHLO advertised URL''' receives ''forwarding requests''; that is, requests for establishing a [[forwarding agreement]]. The server of the URL is an MTA ready to grant such agreements. The client is an MTA configured with a [[forwarding recipe]], that is willing to relay related messages under an agreement. As its name says, this URL is advertised by the server in its EHLO response.

The client is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Client and server are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
Visiting this URL constitutes the first of the three steps provided for setting up a forwarding agreement. The URL itself may change as needed, since it is only used once for each request. The clients posts (or ''sends'', if using SMTP transport) the essential data that defines the agreement:

* The ''recipe-ID''; that is, the key or authentication code of the agreement, as known by the client.
* The ''recipe name''; this should be the incoming address at the client's in the case of static forwarding, or the newsletter or mailing list name. It should be human readable.
* The ''recipient address(es)''; the target addresses at the server's. The server will transform these into the agreement's [[forwarding agreement#user-ID|user-ID]], according to its internal data structures.
* The agreement's ''category'', one of the [[forwarding agreement#category|types defined]].
* The [[policy negotiation URL]], where the server will in turn pay a visit.
* Optionally, the ''Forwarder-ID''; this is the identity of the client as known by the server, in case the client has already entered into an agreement with the same server.
* Optionally, any evidence that may be relevant. For example, the IP address and GMT date of the user's opt-in.

The tentative list above is meant to comprise all the data to fully describe the forwarder's intentions.

The recipe-ID will be used by the server to identify itself when it will, in turn, pay a visit to the supplied policy negotiation URL. By contrast, the ''recipe name'' is what will be visible to users and should meaningfully identify the forwarding.

The client is not authenticated at this stage. If a ''Forwarder-ID'' is supplied, the server should verify that the policy negotiation URL coincides with the one already stored for that ID. If not recognized, the server must not use the supplied ''Forwarder-ID'' for making decisions, but may use it as a hint to synthesize the content of the corresponding field of the agreement.

The server should carry out any verification that it wishes. If supplied evidence includes IP addresses that the server can verify, it should do so before they possibly change and before relevant log files are obliterated. Notice that, except for evidence, no IP addresses are involved.

=== Server response ===
The server may take several paths. When the client is known and trustworthy, the server may visit the policy URL on the fly and respond to the requester process accordingly. Likewise, if the server can estimate that the agreement is likely to be granted within a few hours, it should say so. That information is needed by the client in order to decide how to queue the message at hand.

If any verification fails, the server may reject the request and let the client try again with a better request. If the request mentions an agreement that has already been established, the server should just signal that this is a spoof retrial.

If the server requires human intervention, or other lengthy process that may eventually result in negotiating a policy and granting the agreement, it should signal so. In this case the client marks the recipe as having an agreement underway, and continues to relay as usual meanwhile. It is the server responsibility to eventually visit the policy negotiation URL, possibly for the sole purpose of canceling the pending request.

Notice that it may be convenient for the server to grant an agreement to a known spammer for the sole purpose of rejecting any mail identified that way.</text>
    <sha1>c0c08d9195b26f829d9a222df05dfda98d3a7096</sha1>
  </revision>
  <revision>
    <id>1482</id>
    <parentid>1481</parentid>
    <timestamp>2008-12-27T16:05:53Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Semantics */ rename recipe-ID to recipe-KEY</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4178" xml:space="preserve">The '''EHLO advertised URL''' receives ''forwarding requests''; that is, requests for establishing a [[forwarding agreement]]. The server of the URL is an MTA ready to grant such agreements. The client is an MTA configured with a [[forwarding recipe]], that is willing to relay related messages under an agreement. As its name says, this URL is advertised by the server in its EHLO response.

The client is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Client and server are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
Visiting this URL constitutes the first of the three steps provided for setting up a forwarding agreement. The URL itself may change as needed, since it is only used once for each request. The clients posts (or ''sends'', if using SMTP transport) the essential data that defines the agreement:

* The ''recipe-KEY''; that is, the authentication code of the agreement, as known by the client.
* The ''recipe name''; this should be the incoming address at the client's in the case of static forwarding, or the newsletter or mailing list name. It should be human readable.
* The ''recipient address(es)''; the target addresses at the server's. The server will transform these into the agreement's [[forwarding agreement#user-ID|user-ID]], according to its internal data structures.
* The agreement's ''category'', one of the [[forwarding agreement#category|types defined]].
* The [[policy negotiation URL]], where the server will in turn pay a visit.
* Optionally, the ''Forwarder-ID''; this is the identity of the client as known by the server, in case the client has already entered into an agreement with the same server.
* Optionally, any evidence that may be relevant. For example, the IP address and GMT date of the user's opt-in.

The tentative list above is meant to comprise all the data to fully describe the forwarder's intentions.

The recipe-KEY will be used by the server to identify itself when it will, in turn, pay a visit to the supplied policy negotiation URL. By contrast, the ''recipe name'' is what will be visible to users and should meaningfully identify the forwarding.

The client is not authenticated at this stage. If a ''Forwarder-ID'' is supplied, the server should verify that the policy negotiation URL coincides with the one already stored for that ID. If not recognized, the server must not use the supplied ''Forwarder-ID'' for making decisions, but may use it as a hint to synthesize the content of the corresponding field of the agreement.

The server should carry out any verification that it wishes. If supplied evidence includes IP addresses that the server can verify, it should do so before they possibly change and before relevant log files are obliterated. Notice that, except for evidence, no IP addresses are involved.

=== Server response ===
The server may take several paths. When the client is known and trustworthy, the server may visit the policy URL on the fly and respond to the requester process accordingly. Likewise, if the server can estimate that the agreement is likely to be granted within a few hours, it should say so. That information is needed by the client in order to decide how to queue the message at hand.

If any verification fails, the server may reject the request and let the client try again with a better request. If the request mentions an agreement that has already been established, the server should just signal that this is a spoof retrial.

If the server requires human intervention, or other lengthy process that may eventually result in negotiating a policy and granting the agreement, it should signal so. In this case the client marks the recipe as having an agreement underway, and continues to relay as usual meanwhile. It is the server responsibility to eventually visit the policy negotiation URL, possibly for the sole purpose of canceling the pending request.

Notice that it may be convenient for the server to grant an agreement to a known spammer for the sole purpose of rejecting any mail identified that way.</text>
    <sha1>33d1b2b3537c2f9654983f043bf89190a35e64b5</sha1>
  </revision>
  <revision>
    <id>1483</id>
    <parentid>1482</parentid>
    <timestamp>2008-12-27T16:14:17Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Semantics */ need both an ID and a KEY for a recipe</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4204" xml:space="preserve">The '''EHLO advertised URL''' receives ''forwarding requests''; that is, requests for establishing a [[forwarding agreement]]. The server of the URL is an MTA ready to grant such agreements. The client is an MTA configured with a [[forwarding recipe]], that is willing to relay related messages under an agreement. As its name says, this URL is advertised by the server in its EHLO response.

The client is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Client and server are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
Visiting this URL constitutes the first of the three steps provided for setting up a forwarding agreement. The URL itself may change as needed, since it is only used once for each request. The clients posts (or ''sends'', if using SMTP transport) the essential data that defines the agreement:

* The ''recipe-ID'' as known by the client.
* The ''recipe-KEY'', an authentication code for negotiating the agreement.
* A human readable ''recipe name''.
* The ''recipient address(es)''; the target addresses at the server's. The server will transform these into the agreement's [[forwarding agreement#user-ID|user-ID]], according to its internal data structures.
* The agreement's ''category'', one of the [[forwarding agreement#category|types defined]].
* The [[policy negotiation URL]], where the server will in turn pay a visit.
* Optionally, the ''Forwarder-ID''; this is the identity of the client as known by the server, in case the client has already entered into an agreement with the same server.
* Optionally, any evidence that may be relevant. For example, the IP address and GMT date of the user's opt-in.

The tentative list above is meant to comprise all the data to fully describe the forwarder's intentions.

The recipe-ID and the recipe-KEY will be used by the server to identify itself when it will, in turn, pay a visit to the supplied policy negotiation URL. By contrast, the ''recipe name'' is what will be visible to users and should meaningfully identify the forwarding. The name may be the incoming address at the client's in the case of static forwarding, or the newsletter or mailing list name.

The client is not authenticated at this stage. If a ''Forwarder-ID'' is supplied, the server should verify that the policy negotiation URL coincides with the one already stored for that ID. If not recognized, the server must not use the supplied ''Forwarder-ID'' for making decisions, but may use it as a hint to synthesize the content of the corresponding field of the agreement.

The server should carry out any verification that it wishes. If supplied evidence includes IP addresses that the server can verify, it should do so before they possibly change and before relevant log files are obliterated. Notice that, except for evidence, no IP addresses are involved.

=== Server response ===
The server may take several paths. When the client is known and trustworthy, the server may visit the policy URL on the fly and respond to the requester process accordingly. Likewise, if the server can estimate that the agreement is likely to be granted within a few hours, it should say so. That information is needed by the client in order to decide how to queue the message at hand.

If any verification fails, the server may reject the request and let the client try again with a better request. If the request mentions an agreement that has already been established, the server should just signal that this is a spoof retrial.

If the server requires human intervention, or other lengthy process that may eventually result in negotiating a policy and granting the agreement, it should signal so. In this case the client marks the recipe as having an agreement underway, and continues to relay as usual meanwhile. It is the server responsibility to eventually visit the policy negotiation URL, possibly for the sole purpose of canceling the pending request.

Notice that it may be convenient for the server to grant an agreement to a known spammer for the sole purpose of rejecting any mail identified that way.</text>
    <sha1>6d52bd64bb8b719001a6edd3f39d69b22aed7828</sha1>
  </revision>
  <revision>
    <id>1499</id>
    <parentid>1483</parentid>
    <timestamp>2008-12-28T14:29:12Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Semantics */ spelling and agreement-ID</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4344" xml:space="preserve">The '''EHLO advertised URL''' receives ''forwarding requests''; that is, requests for establishing a [[forwarding agreement]]. The server of the URL is an MTA ready to grant such agreements. The client is an MTA configured with a [[forwarding recipe]], that is willing to relay related messages under an agreement. As its name says, this URL is advertised by the server in its EHLO response.

The client is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Client and server are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
Visiting this URL constitutes the first of the three steps provided for setting up a forwarding agreement. The URL itself may change as needed, since it is only used once for each request. The clients posts (or ''sends'', if using SMTP transport) the essential data that defines the agreement:

* The ''recipe-ID'' as known by the client.
* The ''recipe-KEY'', an authentication code for negotiating the agreement.
* A human readable ''recipe name''.
* The ''recipient address(es)''; the target addresses at the server's. The server will transform these into the agreement's [[forwarding agreement#user-ID|user-ID]], according to its internal data structures.
* The agreement's ''category'', one of the [[forwarding agreement#category|types defined]].
* The [[policy negotiation URL]], where the server will in turn pay a visit.
* Optionally, the ''forwarder-ID''; this is the identity of the client as known by the server, in case the client has already entered into an agreement with the same server.
* Optionally, any evidence that may be relevant. For example, the IP address and GMT date of the user's opt-in.

The tentative list above is meant to comprise all the data to fully describe the forwarder's intentions.

The recipe-ID and the recipe-KEY will be used by the server to identify itself when it will, in turn, pay a visit to the supplied policy negotiation URL. By contrast, the ''recipe name'' is what will be visible to users and should meaningfully identify the forwarding. The name may be the incoming address at the client's in the case of static forwarding, or the newsletter or mailing list name.

The client is not authenticated at this stage. If a ''forwarder-ID'' is supplied, the server should verify that the policy negotiation URL coincides with the one already stored for that ID. If not recognized, the server must not use the supplied ''forwarder-ID'' for making decisions, but may use it as a hint to synthesize the content of the corresponding field of the agreement.

The server should carry out any verification that it wishes. If supplied evidence includes IP addresses that the server can verify, it should do so before they possibly change and before relevant log files are obliterated. Notice that, except for evidence, no IP addresses are involved.

=== Server response ===
The server accepts the request by creating an ''agreement-ID'' and communicating it to the client. The agreement-ID is a key to all related data, including the recipient address(es). The recipe-ID may be used as a prefix to create agreement-IDs that relate to the same remote recipe.

The server may take several paths. If the server can estimate that the agreement is likely to be granted within a few hours, it should say so. That information is needed by the client in order to decide how to queue the message at hand.

If any verification fails, the server may reject the current request and let the client try again with a better one. If the request mentions an agreement that has already been established, the server should just signal that this is a spoof retrial.

If the server requires human intervention, or other lengthy process that may eventually result in negotiating a policy and granting the agreement, it should signal so. In this case the client marks the recipe as having an agreement underway, and continues to relay as usual meanwhile. It is the server responsibility to eventually visit the policy negotiation URL, possibly for the sole purpose of canceling the pending request.

Notice that it may be convenient for the server to grant an agreement to a known spammer for the sole purpose of rejecting any mail identified that way.</text>
    <sha1>f7c5c6d3fe8b019a0539db6eb53e4683a0d49926</sha1>
  </revision>
</page>
<page arvcontinue="20081206153830|1455">
  <title>policy negotiation URL</title>
  <ns>0</ns>
  <id>21</id>
  <revision>
    <id>1485</id>
    <timestamp>2008-12-27T19:09:26Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>new page</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5798" xml:space="preserve">The '''policy negotiation URL''' is where a [[forwarding agreement]] is established and maintained. The server of the URL is the MTA that applied for, and possibly obtained, an agreement associated with a specific [[forwarding recipe]]. The client is an MTA who granted the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.

Please note that the client and server roles are exchanged with respect to the other two URLs provided by the handshake. The server is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Server and c are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes.

Every request to this URL must post the elements that identify the recipe and the client, as given in the [[EHLO advertised URL|forwarding request]]:
* the ''recipe-ID'',
* the ''recipe-KEY'', and
* the ''recipient address(es)''.

Notice that the last element(s) may refer to either incoming or target addresses; this specification is not yet final in this respect.

The next element in the body of the request may have a local name of either ''get'' or ''set'', according to the type of request that the client posts. The meaning of the data is roughly identified by one of the following keywords, given along with a short description of the content they identify.

* ''DNSBL'', a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
* ''SPF'', an array of boolean reject/accept values, one for each possible SPF result, and
* ''flags'', the '''enabled''' and '''non-disclosure''' values as mentioned [[forwarding recipe#Policy considerations|here]].

For static recipes, the server must honor a request to ''get forwarders'', that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators.

The recipe-KEY itself can be changed by the client, for security reasons. Additional keys should be added for letting other clients to access recursively. The added keys are those returned for the ''get forwarders'' query. They should have a limited validity. (This is for allowing recursion, and it is left vague, for the time being.)

In addition, ''Forwarder-ID'', ''password'', and ''determination'' are set-only elements that must be set on the first visit. The server may refuse to change its ID afterward. The password is already expired when it is being set, which forces the use of the third [[password/FBL URL]]. Setting a void password equates to saying that the old one is expired. The ''determination'' must be set if the client does not set ''Forwarder-ID'' and ''password'': it is a human readable text explaining why.

Finally, besides ''get'' and ''set'', a ''delete'' element means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned.

=== Credentials and cryptographic support ===
When using HTTPS transport, the client should check and verify the certificate being provided. This is done a couple of protocols upstream of SOAP. The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.

An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts, but the ''Web of Trust'', à la PGP, seems better suited for this task. MTAs already publish cryptographic keys.

An MTA who has been honoring a forwarding agreement for some time, might ask its granters to certify that. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.

An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it know to be a trustworthy MTA. The number of known signers would then be a valid complement of the relevant ''whois'' information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust with suitable coefficients might result in a reliable algorithm. However, that may complicate this specification more than what it's worth.

=== Server response ===
The server must fail for any unrecognized or invalid identification, e.g. in case the client comes in with an unrecognized receipt-ID. The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar minor errors.

For valid ''get'' requests, the server must include a list of values that the client may modify in a subsequent ''set'' request.</text>
    <sha1>05f619c20ce02f7296dedd0a45d811ac1a347156</sha1>
  </revision>
  <revision>
    <id>1489</id>
    <parentid>1485</parentid>
    <timestamp>2008-12-28T11:17:54Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Semantics */ rename password/FBL =&gt; completion, slightly refine recursion</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6257" xml:space="preserve">The '''policy negotiation URL''' is where a [[forwarding agreement]] is established and maintained. The server of the URL is the MTA that applied for, and possibly obtained, an agreement associated with a specific [[forwarding recipe]]. The client is an MTA who granted the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.

Please note that the client and server roles are exchanged with respect to the other two URLs provided by the handshake. The server is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Server and c are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes.

Every request to this URL must post the elements that identify the recipe and the client, as given in the [[EHLO advertised URL|forwarding request]]:
* the ''recipe-ID'',
* the ''recipe-KEY'', and
* the ''recipient address(es)''.

Notice that the last element(s) may refer to either incoming or target addresses; this specification is not yet final in this respect.

The next element in the body of the request may have a local name of ''get'' or ''set'', according to the type of request that the client posts. In the following, we describe the meaning of the data. The format will have to be worked out so as to allow, for each keyword associated with a ''get'' or ''set'' verb, a list of values, or ''named-index=value'' pairs. Example keywords are as follows:

* ''DNSBL'', a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
* ''SPF'', an array of boolean reject/accept values, one for each possible SPF result, and
* ''flags'', the '''enabled''' and '''non-disclosure''' values as mentioned [[forwarding recipe#Policy considerations|here]].

The ''recipe-KEY'' itself can be changed by the client, for security reasons. The client usually is the ''final MTA''; however, it may in turn forward messages under a further agreement. That is to say, the client may also be a Mediator. In that case, it must ask for, and obtain, additional receipt-KEYs that it will eventually return to final MTAs, so that they can access senders recursively.

For static recipes, the server must honor a request to ''get forwarders'', that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators. This is where the additional receipt-KEYs mentioned in the previous paragraph are returned. The ''forwarders'' keyword is going to be get-only, in the sense that ''set forwarders'' is not going to be supported: The final MTA will have to access each upstream host in order to learn or change policy settings.

In addition, ''Forwarder-ID'', ''password'', and ''determination'' are set-only elements that must be set on the first visit. The server may refuse to change its ID afterward. The password is already expired when it is being set, which forces the use of the [[completion URL]]. Setting a void password equates to saying that the old one is expired. The ''determination'' must be set if the client does not set ''Forwarder-ID'' and ''password'': it is a human readable text explaining why.

Finally, besides ''get'' and ''set'', a ''delete'' element means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned.

=== Credentials and cryptographic support ===
When using HTTPS transport, the client should check and verify the certificate being provided. This is done a couple of protocols upstream of SOAP. The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.

An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts, but the ''Web of Trust'', à la PGP, seems better suited for this task. MTAs already publish cryptographic keys.

An MTA who has been honoring a forwarding agreement for some time, might ask its granters to certify that. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.

An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it know to be a trustworthy MTA. The number of known signers would then be a valid complement of the relevant ''whois'' information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust with suitable coefficients might result in a reliable algorithm. However, that may complicate this specification more than what it's worth.

=== Server response ===
The server must fail for any unrecognized or invalid identification, e.g. in case the client comes in with an unrecognized receipt-ID. The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar minor errors.

For valid ''get'' requests, the server must include a list of values that the client may modify in a subsequent ''set'' request.</text>
    <sha1>17e77bf9c081b80abaf0fc332486e8793308264b</sha1>
  </revision>
  <revision>
    <id>1490</id>
    <parentid>1489</parentid>
    <timestamp>2008-12-28T11:22:03Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>wording</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6281" xml:space="preserve">The '''policy negotiation URL''' is where a [[forwarding agreement]] is established and maintained. The server of the URL is the forwarding MTA that applied for, and possibly obtained, an agreement associated with a specific [[forwarding recipe]]. The client is the MTA who granted (or is going to grant) the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.

Please note that the client and server roles are exchanged with respect to the other two handshake URLs. The server is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Server and client are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes.

Every request to this URL must post the elements that identify the recipe and the client, as given in the [[EHLO advertised URL|forwarding request]]:
* the ''recipe-ID'',
* the ''recipe-KEY'', and
* the ''recipient address(es)''.

Notice that the last element(s) may refer to either incoming or target addresses; this specification is not yet final in this respect.

The next element in the body of the request may have a local name of ''get'' or ''set'', according to the type of request that the client posts. In the following, we describe the meaning of the data. The format will have to be worked out so as to allow, for each keyword associated with a ''get'' or ''set'' verb, a list of values, or ''named-index=value'' pairs. Example keywords are as follows:

* ''DNSBL'', a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
* ''SPF'', an array of boolean reject/accept values, one for each possible SPF result, and
* ''flags'', the '''enabled''' and '''non-disclosure''' values as mentioned [[forwarding recipe#Policy considerations|here]].

The ''recipe-KEY'' itself can be changed by the client, for security reasons. The client usually is the ''final MTA''; however, it may in turn forward messages under a further agreement. That is to say, the client may also be a Mediator. In that case, it must ask for, and obtain, additional receipt-KEYs that it will eventually return to final MTAs, so that they can access senders recursively.

For static recipes, the server must honor a request to ''get forwarders'', that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators. This is where the additional receipt-KEYs mentioned in the previous paragraph are returned. The ''forwarders'' keyword is going to be get-only, in the sense that ''set forwarders'' is not going to be supported: The final MTA will have to access each upstream host in order to learn or change policy settings.

In addition, ''Forwarder-ID'', ''password'', and ''determination'' are set-only elements that must be set on the first visit. The server may refuse to change its ID afterward. The password is already expired when it is being set, which forces the use of the [[completion URL]]. Setting a void password equates to saying that the old one is expired. The ''determination'' must be set if the client does not set ''Forwarder-ID'' and ''password'': it is a human readable text explaining why.

Finally, besides ''get'' and ''set'', a ''delete'' element means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned.

=== Credentials and cryptographic support ===
When using HTTPS transport, the client should check and verify the certificate being provided. This is done a couple of protocols upstream of SOAP. The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.

An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts, but the ''Web of Trust'', à la PGP, seems better suited for this task. MTAs already publish cryptographic keys.

An MTA who has been honoring a forwarding agreement for some time, might ask its granters to certify that. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.

An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it know to be a trustworthy MTA. The number of known signers would then be a valid complement of the relevant ''whois'' information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust with suitable coefficients might result in a reliable algorithm. However, that may complicate this specification more than what it's worth.

=== Server response ===
The server must fail for any unrecognized or invalid identification, e.g. in case the client comes in with an unrecognized receipt-ID. The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar minor errors.

For valid ''get'' requests, the server must include a list of values that the client may modify in a subsequent ''set'' request.</text>
    <sha1>7c778bf4abc9fe0b5713402e6a735225aad53fb2</sha1>
  </revision>
  <revision>
    <id>1491</id>
    <parentid>1490</parentid>
    <timestamp>2008-12-28T11:25:35Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Semantics */ recipe-KEY is not unique</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6285" xml:space="preserve">The '''policy negotiation URL''' is where a [[forwarding agreement]] is established and maintained. The server of the URL is the forwarding MTA that applied for, and possibly obtained, an agreement associated with a specific [[forwarding recipe]]. The client is the MTA who granted (or is going to grant) the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.

Please note that the client and server roles are exchanged with respect to the other two handshake URLs. The server is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Server and client are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes.

Every request to this URL must post the elements that identify the recipe and the client, as given in the [[EHLO advertised URL|forwarding request]]:
* the ''recipe-ID'',
* a valid ''recipe-KEY'', and
* the ''recipient address(es)''.

Notice that the last element(s) may refer to either incoming or target addresses; this specification is not yet final in this respect.

The next element in the body of the request may have a local name of ''get'' or ''set'', according to the type of request that the client posts. In the following, we describe the meaning of the data. The format will have to be worked out so as to allow, for each keyword associated with a ''get'' or ''set'' verb, a list of values, or ''named-index=value'' pairs. Example keywords are as follows:

* ''DNSBL'', a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
* ''SPF'', an array of boolean reject/accept values, one for each possible SPF result, and
* ''flags'', the '''enabled''' and '''non-disclosure''' values as mentioned [[forwarding recipe#Policy considerations|here]].

The ''recipe-KEY'' itself can be changed by the client, for security reasons. The client usually is the ''final MTA''; however, it may in turn forward messages under a further agreement. That is to say, the client may also be a Mediator. In that case, it must ask for, and obtain, additional receipt-KEYs that it will eventually return to final MTAs, so that they can access senders recursively.

For static recipes, the server must honor a request to ''get forwarders'', that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators. This is where the additional receipt-KEYs mentioned in the previous paragraph are returned. The ''forwarders'' keyword is going to be get-only, in the sense that ''set forwarders'' is not going to be supported: The final MTA will have to access each upstream host in order to learn or change policy settings.

In addition, ''Forwarder-ID'', ''password'', and ''determination'' are set-only elements that must be set on the first visit. The server may refuse to change its ID afterward. The password is already expired when it is being set, which forces the use of the [[completion URL]]. Setting a void password equates to saying that the old one is expired. The ''determination'' must be set if the client does not set ''Forwarder-ID'' and ''password'': it is a human readable text explaining why.

Finally, besides ''get'' and ''set'', a ''delete'' element means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned.

=== Credentials and cryptographic support ===
When using HTTPS transport, the client should check and verify the certificate being provided. This is done a couple of protocols upstream of SOAP. The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.

An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts, but the ''Web of Trust'', à la PGP, seems better suited for this task. MTAs already publish cryptographic keys.

An MTA who has been honoring a forwarding agreement for some time, might ask its granters to certify that. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.

An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it know to be a trustworthy MTA. The number of known signers would then be a valid complement of the relevant ''whois'' information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust with suitable coefficients might result in a reliable algorithm. However, that may complicate this specification more than what it's worth.

=== Server response ===
The server must fail for any unrecognized or invalid identification, e.g. in case the client comes in with an unrecognized receipt-ID. The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar minor errors.

For valid ''get'' requests, the server must include a list of values that the client may modify in a subsequent ''set'' request.</text>
    <sha1>3338f2188564bde2e522d503bf6a35a27d6f00c6</sha1>
  </revision>
  <revision>
    <id>1492</id>
    <parentid>1491</parentid>
    <timestamp>2008-12-28T11:31:50Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Credentials and cryptographic support */ wording</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6279" xml:space="preserve">The '''policy negotiation URL''' is where a [[forwarding agreement]] is established and maintained. The server of the URL is the forwarding MTA that applied for, and possibly obtained, an agreement associated with a specific [[forwarding recipe]]. The client is the MTA who granted (or is going to grant) the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.

Please note that the client and server roles are exchanged with respect to the other two handshake URLs. The server is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Server and client are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes.

Every request to this URL must post the elements that identify the recipe and the client, as given in the [[EHLO advertised URL|forwarding request]]:
* the ''recipe-ID'',
* a valid ''recipe-KEY'', and
* the ''recipient address(es)''.

Notice that the last element(s) may refer to either incoming or target addresses; this specification is not yet final in this respect.

The next element in the body of the request may have a local name of ''get'' or ''set'', according to the type of request that the client posts. In the following, we describe the meaning of the data. The format will have to be worked out so as to allow, for each keyword associated with a ''get'' or ''set'' verb, a list of values, or ''named-index=value'' pairs. Example keywords are as follows:

* ''DNSBL'', a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
* ''SPF'', an array of boolean reject/accept values, one for each possible SPF result, and
* ''flags'', the '''enabled''' and '''non-disclosure''' values as mentioned [[forwarding recipe#Policy considerations|here]].

The ''recipe-KEY'' itself can be changed by the client, for security reasons. The client usually is the ''final MTA''; however, it may in turn forward messages under a further agreement. That is to say, the client may also be a Mediator. In that case, it must ask for, and obtain, additional receipt-KEYs that it will eventually return to final MTAs, so that they can access senders recursively.

For static recipes, the server must honor a request to ''get forwarders'', that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators. This is where the additional receipt-KEYs mentioned in the previous paragraph are returned. The ''forwarders'' keyword is going to be get-only, in the sense that ''set forwarders'' is not going to be supported: The final MTA will have to access each upstream host in order to learn or change policy settings.

In addition, ''Forwarder-ID'', ''password'', and ''determination'' are set-only elements that must be set on the first visit. The server may refuse to change its ID afterward. The password is already expired when it is being set, which forces the use of the [[completion URL]]. Setting a void password equates to saying that the old one is expired. The ''determination'' must be set if the client does not set ''Forwarder-ID'' and ''password'': it is a human readable text explaining why.

Finally, besides ''get'' and ''set'', a ''delete'' element means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned.

=== Credentials and cryptographic support ===
When using HTTPS transport, the client should download and verify the certificate being provided. This is done a couple of layers below SOAP. The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.

An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts, but the ''Web of Trust'', à la PGP, seems better suited for this task. MTAs already publish cryptographic keys.

An MTA who has been honoring a forwarding agreement for some time, might ask its granters to certify that. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.

An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it know to be a trustworthy MTA. The number of known signers would then be a valid complement of the relevant ''whois'' information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust with suitable coefficients might result in a reliable algorithm. However, that may complicate this specification more than what it's worth.

=== Server response ===
The server must fail for any unrecognized or invalid identification, e.g. in case the client comes in with an unrecognized receipt-ID. The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar minor errors.

For valid ''get'' requests, the server must include a list of values that the client may modify in a subsequent ''set'' request.</text>
    <sha1>618bff757de5a811d7a40b26157469009842e55a</sha1>
  </revision>
  <revision>
    <id>1493</id>
    <parentid>1492</parentid>
    <timestamp>2008-12-28T11:36:17Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Credentials and cryptographic support */ typo</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6284" xml:space="preserve">The '''policy negotiation URL''' is where a [[forwarding agreement]] is established and maintained. The server of the URL is the forwarding MTA that applied for, and possibly obtained, an agreement associated with a specific [[forwarding recipe]]. The client is the MTA who granted (or is going to grant) the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.

Please note that the client and server roles are exchanged with respect to the other two handshake URLs. The server is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Server and client are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes.

Every request to this URL must post the elements that identify the recipe and the client, as given in the [[EHLO advertised URL|forwarding request]]:
* the ''recipe-ID'',
* a valid ''recipe-KEY'', and
* the ''recipient address(es)''.

Notice that the last element(s) may refer to either incoming or target addresses; this specification is not yet final in this respect.

The next element in the body of the request may have a local name of ''get'' or ''set'', according to the type of request that the client posts. In the following, we describe the meaning of the data. The format will have to be worked out so as to allow, for each keyword associated with a ''get'' or ''set'' verb, a list of values, or ''named-index=value'' pairs. Example keywords are as follows:

* ''DNSBL'', a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
* ''SPF'', an array of boolean reject/accept values, one for each possible SPF result, and
* ''flags'', the '''enabled''' and '''non-disclosure''' values as mentioned [[forwarding recipe#Policy considerations|here]].

The ''recipe-KEY'' itself can be changed by the client, for security reasons. The client usually is the ''final MTA''; however, it may in turn forward messages under a further agreement. That is to say, the client may also be a Mediator. In that case, it must ask for, and obtain, additional receipt-KEYs that it will eventually return to final MTAs, so that they can access senders recursively.

For static recipes, the server must honor a request to ''get forwarders'', that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators. This is where the additional receipt-KEYs mentioned in the previous paragraph are returned. The ''forwarders'' keyword is going to be get-only, in the sense that ''set forwarders'' is not going to be supported: The final MTA will have to access each upstream host in order to learn or change policy settings.

In addition, ''Forwarder-ID'', ''password'', and ''determination'' are set-only elements that must be set on the first visit. The server may refuse to change its ID afterward. The password is already expired when it is being set, which forces the use of the [[completion URL]]. Setting a void password equates to saying that the old one is expired. The ''determination'' must be set if the client does not set ''Forwarder-ID'' and ''password'': it is a human readable text explaining why.

Finally, besides ''get'' and ''set'', a ''delete'' element means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned.

=== Credentials and cryptographic support ===
When using HTTPS transport, the client should download and verify the certificate being provided. This is done a couple of layers below SOAP. The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.

An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts, but the ''Web of Trust'', à la PGP, seems better suited for this task. MTAs already publish cryptographic keys.

An MTA who has been honoring a forwarding agreement for some time, might ask its granters to certify that. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.

An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it knows to be a trustworthy peer. The number of known signers would then be a valid complement of the relevant ''whois'' information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust (with suitable coefficients) might result in a reliable algorithm. However, that may complicate this specification more than what it is worth.

=== Server response ===
The server must fail for any unrecognized or invalid identification, e.g. in case the client comes in with an unrecognized receipt-ID. The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar minor errors.

For valid ''get'' requests, the server must include a list of values that the client may modify in a subsequent ''set'' request.</text>
    <sha1>6e2bdebe25c496ea19490b2726a75383a9c2899c</sha1>
  </revision>
  <revision>
    <id>1494</id>
    <parentid>1493</parentid>
    <timestamp>2008-12-28T12:17:34Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Server response */ expand status</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7944" xml:space="preserve">The '''policy negotiation URL''' is where a [[forwarding agreement]] is established and maintained. The server of the URL is the forwarding MTA that applied for, and possibly obtained, an agreement associated with a specific [[forwarding recipe]]. The client is the MTA who granted (or is going to grant) the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.

Please note that the client and server roles are exchanged with respect to the other two handshake URLs. The server is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Server and client are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes.

Every request to this URL must post the elements that identify the recipe and the client, as given in the [[EHLO advertised URL|forwarding request]]:
* the ''recipe-ID'',
* a valid ''recipe-KEY'', and
* the ''recipient address(es)''.

Notice that the last element(s) may refer to either incoming or target addresses; this specification is not yet final in this respect.

The next element in the body of the request may have a local name of ''get'' or ''set'', according to the type of request that the client posts. In the following, we describe the meaning of the data. The format will have to be worked out so as to allow, for each keyword associated with a ''get'' or ''set'' verb, a list of values, or ''named-index=value'' pairs. Example keywords are as follows:

* ''DNSBL'', a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
* ''SPF'', an array of boolean reject/accept values, one for each possible SPF result, and
* ''flags'', the '''enabled''' and '''non-disclosure''' values as mentioned [[forwarding recipe#Policy considerations|here]].

The ''recipe-KEY'' itself can be changed by the client, for security reasons. The client usually is the ''final MTA''; however, it may in turn forward messages under a further agreement. That is to say, the client may also be a Mediator. In that case, it must ask for, and obtain, additional receipt-KEYs that it will eventually return to final MTAs, so that they can access senders recursively.

For static recipes, the server must honor a request to ''get forwarders'', that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators. This is where the additional receipt-KEYs mentioned in the previous paragraph are returned. The ''forwarders'' keyword is going to be get-only, in the sense that ''set forwarders'' is not going to be supported: The final MTA will have to access each upstream host in order to learn or change policy settings.

In addition, ''Forwarder-ID'', ''password'', and ''determination'' are set-only elements that must be set on the first visit. The server may refuse to change its ID afterward. The password is already expired when it is being set, which forces the use of the [[completion URL]]. Setting a void password equates to saying that the old one is expired. The ''determination'' must be set if the client does not set ''Forwarder-ID'' and ''password'': it is a human readable text explaining why.

Finally, besides ''get'' and ''set'', a ''delete'' element means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned.

=== Credentials and cryptographic support ===
When using HTTPS transport, the client should download and verify the certificate being provided. This is done a couple of layers below SOAP. The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.

An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts, but the ''Web of Trust'', à la PGP, seems better suited for this task. MTAs already publish cryptographic keys.

An MTA who has been honoring a forwarding agreement for some time, might ask its granters to certify that. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.

An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it knows to be a trustworthy peer. The number of known signers would then be a valid complement of the relevant ''whois'' information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust (with suitable coefficients) might result in a reliable algorithm. However, that may complicate this specification more than what it is worth.

=== Server response ===
The server must fail for any unrecognized or invalid identification, in case the client comes in with a nonexistent receipt-ID, or invalid recipient address(es). The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar errors possibly due to lack of synchronization.

For valid ''get'' requests, the server must include a list of values that the client may modify in a subsequent ''set'' request.

Positive responses should always include the status of the agreement. It remains ''underway'' until a Forwarder-ID/password pair has not been set. Afterward it switches to ''pending completion'' until a valid password has been set. Eventually it will be ''complete''. The server should react to a determination setting, that is the client's refusal to grant the agreement, by deleting all data, as if receiving a ''delete'' verb.

It goes without saying that, after it has acknowledged a given set of options, the server must honor those settings. Effective changes are not necessarily synchronous, but must be carried out withing a reasonable amount of hours. If this URL is being serviced by a different machine than the one that hosts the recipe, and the latter is currently down or disconnected, fulfilling the request has to be delayed. Obviously, mail must not be relayed by an MTA which is down or disconnected. Settings must take place within a few hours after that MTA gets back into operations.

A delete request, or a determination not to grant a forwarding agreement, implies to '''remove all occurrences of the relevant email address(es)''' from the forwarding recipe. For static recipes, that usually means to delete the recipe altogether. The status of the agreement switches to ''deleted'', and the server shall continue to acknowledge valid requests about it, until the delete operation is actually completed. That is to say, the recipe data and keys used to service this URL must be deleted ''after'' the recipe data that make forwarding possible. Thereafter, requests will fail.</text>
    <sha1>c6729252b1055cd32a38ce7af9082b17df42d06f</sha1>
  </revision>
  <revision>
    <id>1495</id>
    <parentid>1494</parentid>
    <timestamp>2008-12-28T12:23:22Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Semantics */ once, not on the first visit</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7965" xml:space="preserve">The '''policy negotiation URL''' is where a [[forwarding agreement]] is established and maintained. The server of the URL is the forwarding MTA that applied for, and possibly obtained, an agreement associated with a specific [[forwarding recipe]]. The client is the MTA who granted (or is going to grant) the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.

Please note that the client and server roles are exchanged with respect to the other two handshake URLs. The server is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Server and client are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes.

Every request to this URL must post the elements that identify the recipe and the client, as given in the [[EHLO advertised URL|forwarding request]]:
* the ''recipe-ID'',
* a valid ''recipe-KEY'', and
* the ''recipient address(es)''.

Notice that the last element(s) may refer to either incoming or target addresses; this specification is not yet final in this respect.

The next element in the body of the request may have a local name of ''get'' or ''set'', according to the type of request that the client posts. In the following, we describe the meaning of the data. The format will have to be worked out so as to allow, for each keyword associated with a ''get'' or ''set'' verb, a list of values, or ''named-index=value'' pairs. Example keywords are as follows:

* ''DNSBL'', a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
* ''SPF'', an array of boolean reject/accept values, one for each possible SPF result, and
* ''flags'', the '''enabled''' and '''non-disclosure''' values as mentioned [[forwarding recipe#Policy considerations|here]].

The ''recipe-KEY'' itself can be changed by the client, for security reasons. The client usually is the ''final MTA''; however, it may in turn forward messages under a further agreement. That is to say, the client may also be a Mediator. In that case, it must ask for, and obtain, additional receipt-KEYs that it will eventually return to final MTAs, so that they can access senders recursively.

For static recipes, the server must honor a request to ''get forwarders'', that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators. This is where the additional receipt-KEYs mentioned in the previous paragraph are returned. The ''forwarders'' keyword is going to be get-only, in the sense that ''set forwarders'' is not going to be supported: The final MTA will have to access each upstream host in order to learn or change policy settings.

In addition, ''Forwarder-ID'', ''password'', and ''determination'' are set-only elements that must be set once, before the agreement is completed. The server may refuse to change its ID afterward. The password is already expired when it is being set, which forces the use of the [[completion URL]]. Setting a void password equates to saying that the old one is expired. The ''determination'' must be set if the client does not set ''Forwarder-ID'' and ''password'': it is a human readable text explaining why.

Finally, besides ''get'' and ''set'', a ''delete'' element means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned.

=== Credentials and cryptographic support ===
When using HTTPS transport, the client should download and verify the certificate being provided. This is done a couple of layers below SOAP. The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.

An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts, but the ''Web of Trust'', à la PGP, seems better suited for this task. MTAs already publish cryptographic keys.

An MTA who has been honoring a forwarding agreement for some time, might ask its granters to certify that. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.

An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it knows to be a trustworthy peer. The number of known signers would then be a valid complement of the relevant ''whois'' information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust (with suitable coefficients) might result in a reliable algorithm. However, that may complicate this specification more than what it is worth.

=== Server response ===
The server must fail for any unrecognized or invalid identification, in case the client comes in with a nonexistent receipt-ID, or invalid recipient address(es). The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar errors possibly due to lack of synchronization.

For valid ''get'' requests, the server must include a list of values that the client may modify in a subsequent ''set'' request.

Positive responses should always include the status of the agreement. It remains ''underway'' until a Forwarder-ID/password pair has not been set. Afterward it switches to ''pending completion'' until a valid password has been set. Eventually it will be ''complete''. The server should react to a determination setting, that is the client's refusal to grant the agreement, by deleting all data, as if receiving a ''delete'' verb.

It goes without saying that, after it has acknowledged a given set of options, the server must honor those settings. Effective changes are not necessarily synchronous, but must be carried out withing a reasonable amount of hours. If this URL is being serviced by a different machine than the one that hosts the recipe, and the latter is currently down or disconnected, fulfilling the request has to be delayed. Obviously, mail must not be relayed by an MTA which is down or disconnected. Settings must take place within a few hours after that MTA gets back into operations.

A delete request, or a determination not to grant a forwarding agreement, implies to '''remove all occurrences of the relevant email address(es)''' from the forwarding recipe. For static recipes, that usually means to delete the recipe altogether. The status of the agreement switches to ''deleted'', and the server shall continue to acknowledge valid requests about it, until the delete operation is actually completed. That is to say, the recipe data and keys used to service this URL must be deleted ''after'' the recipe data that make forwarding possible. Thereafter, requests will fail.</text>
    <sha1>4c1d534156e847b60327d136ab12284589e44326</sha1>
  </revision>
  <revision>
    <id>1496</id>
    <parentid>1495</parentid>
    <timestamp>2008-12-28T12:27:57Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Semantics */ completed agreements for additional KEYs</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8066" xml:space="preserve">The '''policy negotiation URL''' is where a [[forwarding agreement]] is established and maintained. The server of the URL is the forwarding MTA that applied for, and possibly obtained, an agreement associated with a specific [[forwarding recipe]]. The client is the MTA who granted (or is going to grant) the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.

Please note that the client and server roles are exchanged with respect to the other two handshake URLs. The server is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Server and client are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes.

Every request to this URL must post the elements that identify the recipe and the client, as given in the [[EHLO advertised URL|forwarding request]]:
* the ''recipe-ID'',
* a valid ''recipe-KEY'', and
* the ''recipient address(es)''.

Notice that the last element(s) may refer to either incoming or target addresses; this specification is not yet final in this respect.

The next element in the body of the request may have a local name of ''get'' or ''set'', according to the type of request that the client posts. In the following, we describe the meaning of the data. The format will have to be worked out so as to allow, for each keyword associated with a ''get'' or ''set'' verb, a list of values, or ''named-index=value'' pairs. Example keywords are as follows:

* ''DNSBL'', a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
* ''SPF'', an array of boolean reject/accept values, one for each possible SPF result, and
* ''flags'', the '''enabled''' and '''non-disclosure''' values as mentioned [[forwarding recipe#Policy considerations|here]].

The ''recipe-KEY'' itself can be changed by the client, for security reasons. The client usually is the ''final MTA''; however, it may in turn forward messages under a further agreement. That is to say, the client may also be a Mediator. In that case, it must ask for, and obtain, additional receipt-KEYs that it will eventually return to final MTAs, so that they can access senders recursively.

For static recipes and completed agreements, the server must honor a request to ''get forwarders'', that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators. This is where the additional receipt-KEYs mentioned in the previous paragraph are returned. The ''forwarders'' keyword is going to be get-only, in the sense that ''set forwarders'' is not going to be supported: The final MTA will have to access each upstream host in order to learn or change policy settings.

In addition, ''Forwarder-ID'', ''password'', and ''determination'' are set-only elements that must be set once, before the agreement is completed. The server may refuse to change its ID afterward. The password is already expired when it is being set, which forces the use of the [[completion URL]]. Setting a void password equates to saying that the old one is expired. The ''determination'' must be set if the client does not set ''Forwarder-ID'' and ''password'': it is a human readable text explaining why.

Finally, besides ''get'' and ''set'', a ''delete'' element may be posted to a completed agreement. It means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned (See [[#Server response|below]].)

=== Credentials and cryptographic support ===
When using HTTPS transport, the client should download and verify the certificate being provided. This is done a couple of layers below SOAP. The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.

An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts, but the ''Web of Trust'', à la PGP, seems better suited for this task. MTAs already publish cryptographic keys.

An MTA who has been honoring a forwarding agreement for some time, might ask its granters to certify that. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.

An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it knows to be a trustworthy peer. The number of known signers would then be a valid complement of the relevant ''whois'' information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust (with suitable coefficients) might result in a reliable algorithm. However, that may complicate this specification more than what it is worth.

=== Server response ===
The server must fail for any unrecognized or invalid identification, in case the client comes in with a nonexistent receipt-ID, or invalid recipient address(es). The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar errors possibly due to lack of synchronization.

For valid ''get'' requests, the server must include a list of values that the client may modify in a subsequent ''set'' request.

Positive responses should always include the status of the agreement. It remains ''underway'' until a Forwarder-ID/password pair has not been set. Afterward it switches to ''pending completion'' until a valid password has been set. Eventually it will be ''complete''. The server should react to a determination setting, that is the client's refusal to grant the agreement, by deleting all data, as if receiving a ''delete'' verb.

It goes without saying that, after it has acknowledged a given set of options, the server must honor those settings. Effective changes are not necessarily synchronous, but must be carried out withing a reasonable amount of hours. If this URL is being serviced by a different machine than the one that hosts the recipe, and the latter is currently down or disconnected, fulfilling the request has to be delayed. Obviously, mail must not be relayed by an MTA which is down or disconnected. Settings must take place within a few hours after that MTA gets back into operations.

A delete request, or a determination not to grant a forwarding agreement, implies to '''remove all occurrences of the relevant email address(es)''' from the forwarding recipe. For static recipes, that usually means to delete the recipe altogether. The status of the agreement switches to ''deleted'', and the server shall continue to acknowledge valid requests about it, until the delete operation is actually completed. That is to say, the recipe data and keys used to service this URL must be deleted ''after'' the recipe data that make forwarding possible. Thereafter, requests will fail.</text>
    <sha1>fe250e7bc17c72003e146e55a8a6a57621752077</sha1>
  </revision>
  <revision>
    <id>1498</id>
    <parentid>1496</parentid>
    <timestamp>2008-12-28T13:54:51Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Semantics */ completion URL can be changed here too</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8139" xml:space="preserve">The '''policy negotiation URL''' is where a [[forwarding agreement]] is established and maintained. The server of the URL is the forwarding MTA that applied for, and possibly obtained, an agreement associated with a specific [[forwarding recipe]]. The client is the MTA who granted (or is going to grant) the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.

Please note that the client and server roles are exchanged with respect to the other two handshake URLs. The server is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Server and client are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes.

Every request to this URL must post the elements that identify the recipe and the client, as given in the [[EHLO advertised URL|forwarding request]]:
* the ''recipe-ID'',
* a valid ''recipe-KEY'', and
* the ''recipient address(es)''.

Notice that the last element(s) may refer to either incoming or target addresses; this specification is not yet final in this respect.

The next element in the body of the request may have a local name of ''get'' or ''set'', according to the type of request that the client posts. In the following, we describe the meaning of the data. The format will have to be worked out so as to allow, for each keyword associated with a ''get'' or ''set'' verb, a list of values, or ''named-index=value'' pairs. Example keywords are as follows:

* ''DNSBL'', a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
* ''SPF'', an array of boolean reject/accept values, one for each possible SPF result, and
* ''flags'', the '''enabled''' and '''non-disclosure''' values as mentioned [[forwarding recipe#Policy considerations|here]].

The ''recipe-KEY'' itself can be changed by the client, for security reasons. The client usually is the ''final MTA''; however, it may in turn forward messages under a further agreement. That is to say, the client may also be a Mediator. In that case, it must ask for, and obtain, additional receipt-KEYs that it will eventually return to final MTAs, so that they can access senders recursively.

For static recipes and completed agreements, the server must honor a request to ''get forwarders'', that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators. This is where the additional receipt-KEYs mentioned in the previous paragraph are returned. The ''forwarders'' keyword is going to be get-only, in the sense that ''set forwarders'' is not going to be supported: The final MTA will have to access each upstream host in order to learn or change policy settings.

In addition, ''Forwarder-ID'', ''password'', ''[[completion URL]]'' and ''determination'' are set-only elements that must be set once, before the agreement is completed. The server may refuse to change its ID afterward. The password is already expired when it is being set, which forces the use of the completion URL. Setting a void password equates to saying that the old one is expired. The ''determination'' must be set if the client does not set ''Forwarder-ID'' and ''password'': it is a human readable text explaining why.

Finally, besides ''get'' and ''set'', a ''delete'' element may be posted to a completed agreement. It means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned (See [[#Server response|below]].)

=== Credentials and cryptographic support ===
When using HTTPS transport, the client should download and verify the certificate being provided. This is done a couple of layers below SOAP. The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.

An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts, but the ''Web of Trust'', à la PGP, seems better suited for this task. MTAs already publish cryptographic keys.

An MTA who has been honoring a forwarding agreement for some time, might ask its granters to certify that. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.

An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it knows to be a trustworthy peer. The number of known signers would then be a valid complement of the relevant ''whois'' information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust (with suitable coefficients) might result in a reliable algorithm. However, that may complicate this specification more than what it is worth.

=== Server response ===
The server must fail for any unrecognized or invalid identification, in case the client comes in with a nonexistent receipt-ID, or invalid recipient address(es). The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar errors possibly due to lack of synchronization.

For valid ''get'' requests, the server must include a list of values that the client may modify in a subsequent ''set'' request.

Positive responses should always include the status of the agreement. It remains ''underway'' until a Forwarder-ID/password pair and completion URL have not been set. Afterward it switches to ''pending completion'' until a valid password has been set by visiting the URL thus provided. Eventually it will be ''complete''. The server should react to a determination setting, that is the client's refusal to grant the agreement, by deleting all data, as if receiving a ''delete'' verb.

It goes without saying that, after it has acknowledged a given set of options, the server must honor those settings. Effective changes are not necessarily synchronous, but must be carried out withing a reasonable amount of hours. If this URL is being serviced by a different machine than the one that hosts the recipe, and the latter is currently down or disconnected, fulfilling the request has to be delayed. Obviously, mail must not be relayed by an MTA which is down or disconnected. Settings must take place within a few hours after that MTA gets back into operations.

A delete request, or a determination not to grant a forwarding agreement, implies to '''remove all occurrences of the relevant email address(es)''' from the forwarding recipe. For static recipes, that usually means to delete the recipe altogether. The status of the agreement switches to ''deleted'', and the server shall continue to acknowledge valid requests about it, until the delete operation is actually completed. That is to say, the recipe data and keys used to service this URL must be deleted ''after'' the recipe data that make forwarding possible. Thereafter, requests will fail.</text>
    <sha1>f9cbea018c628ac3500dbbbdd5700398ef63d51e</sha1>
  </revision>
  <revision>
    <id>1500</id>
    <parentid>1498</parentid>
    <timestamp>2008-12-28T14:49:07Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Semantics */ agreement-ID</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8290" xml:space="preserve">The '''policy negotiation URL''' is where a [[forwarding agreement]] is established and maintained. The server of the URL is the forwarding MTA that applied for, and possibly obtained, an agreement associated with a specific [[forwarding recipe]]. The client is the MTA who granted (or is going to grant) the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.

Please note that the client and server roles are exchanged with respect to the other two handshake URLs. The server is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Server and client are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes as well as database design.

Every request to this URL must post the elements that identify the recipe and the client, as given in the [[EHLO advertised URL|forwarding request]]:
* the ''recipe-ID'',
* a valid ''recipe-KEY'', and
* the ''agreement-ID''.

The recipe-ID and the agreement-ID unambiguously identify the relevant (target) recipient address(es). The recipe-KEY authenticates the client.

The next element in the body of the request may have a local name of ''get'' or ''set'', according to the type of request that the client posts. In the following, we describe the meaning of the data. The format will have to be worked out so as to allow, for each keyword associated with a ''get'' or ''set'' verb, a list of values, or ''named-index=value'' pairs. Example keywords are as follows:

* ''DNSBL'', a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
* ''SPF'', an array of boolean reject/accept values, one for each possible SPF result, and
* ''flags'', the '''enabled''' and '''non-disclosure''' values as mentioned [[forwarding recipe#Policy considerations|here]].

The ''recipe-KEY'' itself can be changed by the client, for security reasons. The client usually is the ''final MTA''; however, it may in turn forward messages under a further agreement. That is to say, the client may also be a Mediator. In that case, it must ask for, and obtain, additional receipt-KEYs that it will eventually return to final MTAs, so that they can access senders recursively.

For static recipes and completed agreements, the server must honor a request to ''get forwarders'', that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators. This is where the additional receipt-KEYs mentioned in the previous paragraph are returned. The ''forwarders'' keyword is going to be get-only, in the sense that ''set forwarders'' is not going to be supported: The final MTA will have to access each upstream host in order to learn or change policy settings.

In addition, ''forwarder-ID'', ''password'', ''[[completion URL]]'' and ''determination'' are set-only elements that must be set once, before the agreement is completed. The server may refuse to change its ID afterward. The password is already expired when it is being set, which forces the use of the completion URL. Setting a void password equates to saying that the old one is expired. The ''determination'' must be set if the client does not set ''forwarder-ID'' and ''password'': it is a human readable text explaining why.

Finally, besides ''get'' and ''set'', a ''delete'' element may be posted to a completed agreement. It means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned (See [[#Server response|below]].)

=== Credentials and cryptographic support ===
When using HTTPS transport, the client should download and verify the certificate being provided. This is done a couple of layers below SOAP. The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.

An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts and tools. However, a ''Web of Trust'', à la PGP, seems better suited for this task. MTAs already publish cryptographic keys. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.

An MTA who has been honoring a forwarding agreement for some time, might ask its peer to certify that. The receiving MTA should have collected enough data to conclude that a forwarder is not a spammer, before signing.

An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it knows to be a trustworthy peer. The number of known signers would then be a valid complement of the relevant ''whois'' information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust (with suitable coefficients) might result in a reliable algorithm. However, that may complicate this specification more than what it is worth.

=== Server response ===
The server must fail for any unrecognized or invalid identification, in case the client comes in with a nonexistent receipt-ID, or invalid recipient address(es). The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar errors possibly due to lack of synchronization.

For valid ''get'' requests, the server must include a list of values that the client may modify in a subsequent ''set'' request.

Positive responses should always include the status of the agreement. It remains ''underway'' until a forwarder-ID/password pair and completion URL have not been set. Afterward it switches to ''pending completion'' until a valid password has been set by visiting the URL thus provided. Eventually it will be ''complete''. The server should react to a determination setting, that is the client's refusal to grant the agreement, by deleting all data, as if receiving a ''delete'' verb.

It goes without saying that, after it has acknowledged a given set of options, the server must honor those settings. Effective changes are not necessarily synchronous, but must be carried out withing a reasonable amount of hours. If this URL is being serviced by a different machine than the one that hosts the recipe, and the latter is currently down or disconnected, fulfilling the request has to be delayed. Obviously, mail must not be relayed by an MTA which is down or disconnected. Settings must take place within a few hours after that MTA gets back into operations.

A delete request, or a determination not to grant a forwarding agreement, implies to '''remove all occurrences of the relevant email address(es)''' from the forwarding recipe. For static recipes, that usually means to delete the recipe altogether. The status of the agreement switches to ''deleted'', and the server shall continue to acknowledge valid requests about it, until the delete operation is actually completed. That is to say, the recipe data and keys used to service this URL must be deleted ''after'' the recipe data that make forwarding possible. Thereafter, requests will fail.</text>
    <sha1>164695aa66e066c0ab5f19bb539e2bf5e6585a76</sha1>
  </revision>
  <revision>
    <id>1501</id>
    <parentid>1500</parentid>
    <timestamp>2008-12-28T15:44:48Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Server response */ delete the mailbox!</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8338" xml:space="preserve">The '''policy negotiation URL''' is where a [[forwarding agreement]] is established and maintained. The server of the URL is the forwarding MTA that applied for, and possibly obtained, an agreement associated with a specific [[forwarding recipe]]. The client is the MTA who granted (or is going to grant) the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.

Please note that the client and server roles are exchanged with respect to the other two handshake URLs. The server is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Server and client are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes as well as database design.

Every request to this URL must post the elements that identify the recipe and the client, as given in the [[EHLO advertised URL|forwarding request]]:
* the ''recipe-ID'',
* a valid ''recipe-KEY'', and
* the ''agreement-ID''.

The recipe-ID and the agreement-ID unambiguously identify the relevant (target) recipient address(es). The recipe-KEY authenticates the client.

The next element in the body of the request may have a local name of ''get'' or ''set'', according to the type of request that the client posts. In the following, we describe the meaning of the data. The format will have to be worked out so as to allow, for each keyword associated with a ''get'' or ''set'' verb, a list of values, or ''named-index=value'' pairs. Example keywords are as follows:

* ''DNSBL'', a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
* ''SPF'', an array of boolean reject/accept values, one for each possible SPF result, and
* ''flags'', the '''enabled''' and '''non-disclosure''' values as mentioned [[forwarding recipe#Policy considerations|here]].

The ''recipe-KEY'' itself can be changed by the client, for security reasons. The client usually is the ''final MTA''; however, it may in turn forward messages under a further agreement. That is to say, the client may also be a Mediator. In that case, it must ask for, and obtain, additional receipt-KEYs that it will eventually return to final MTAs, so that they can access senders recursively.

For static recipes and completed agreements, the server must honor a request to ''get forwarders'', that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators. This is where the additional receipt-KEYs mentioned in the previous paragraph are returned. The ''forwarders'' keyword is going to be get-only, in the sense that ''set forwarders'' is not going to be supported: The final MTA will have to access each upstream host in order to learn or change policy settings.

In addition, ''forwarder-ID'', ''password'', ''[[completion URL]]'' and ''determination'' are set-only elements that must be set once, before the agreement is completed. The server may refuse to change its ID afterward. The password is already expired when it is being set, which forces the use of the completion URL. Setting a void password equates to saying that the old one is expired. The ''determination'' must be set if the client does not set ''forwarder-ID'' and ''password'': it is a human readable text explaining why.

Finally, besides ''get'' and ''set'', a ''delete'' element may be posted to a completed agreement. It means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned (See [[#Server response|below]].)

=== Credentials and cryptographic support ===
When using HTTPS transport, the client should download and verify the certificate being provided. This is done a couple of layers below SOAP. The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.

An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts and tools. However, a ''Web of Trust'', à la PGP, seems better suited for this task. MTAs already publish cryptographic keys. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.

An MTA who has been honoring a forwarding agreement for some time, might ask its peer to certify that. The receiving MTA should have collected enough data to conclude that a forwarder is not a spammer, before signing.

An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it knows to be a trustworthy peer. The number of known signers would then be a valid complement of the relevant ''whois'' information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust (with suitable coefficients) might result in a reliable algorithm. However, that may complicate this specification more than what it is worth.

=== Server response ===
The server must fail for any unrecognized or invalid identification, in case the client comes in with a nonexistent receipt-ID, or invalid recipient address(es). The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar errors possibly due to lack of synchronization.

For valid ''get'' requests, the server must include a list of values that the client may modify in a subsequent ''set'' request.

Positive responses should always include the status of the agreement. It remains ''underway'' until a forwarder-ID/password pair and completion URL have not been set. Afterward it switches to ''pending completion'' until a valid password has been set by visiting the URL thus provided. Eventually it will be ''complete''. The server should react to a determination setting, that is the client's refusal to grant the agreement, by deleting all data, as if receiving a ''delete'' verb.

It goes without saying that, after it has acknowledged a given set of options, the server must honor those settings. Effective changes are not necessarily synchronous, but must be carried out withing a reasonable amount of hours. If this URL is being serviced by a different machine than the one that hosts the recipe, and the latter is currently down or disconnected, fulfilling the request has to be delayed. Obviously, mail must not be relayed by an MTA which is down or disconnected. Settings must take place within a few hours after that MTA gets back into operations.

A delete request, or a determination not to grant a forwarding agreement, implies to '''remove all occurrences of the relevant email address(es)''' from the forwarding recipe. For static recipes, that means to delete the recipe ''and'' the mailbox; users might just disable forwarding otherwise. The status of the agreement switches to ''deleted'', and the server shall continue to acknowledge valid requests about it, until the delete operation is actually completed. That is to say, the recipe data and keys used to service this URL must be deleted ''after'' the recipe data that make forwarding possible. Thereafter, requests will fail.</text>
    <sha1>3f0fa7ea1b0dcafec5e9d02101a8f34b0b96e1c3</sha1>
  </revision>
  <revision>
    <id>1504</id>
    <parentid>1501</parentid>
    <timestamp>2008-12-28T17:02:18Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Semantics */ corrections</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8423" xml:space="preserve">The '''policy negotiation URL''' is where a [[forwarding agreement]] is established and maintained. The server of the URL is the forwarding MTA that applied for, and possibly obtained, an agreement associated with a specific [[forwarding recipe]]. The client is the MTA who granted (or is going to grant) the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.

Please note that the client and server roles are exchanged with respect to the other two handshake URLs. The server is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Server and client are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes as well as database design.

Every request to this URL must post the elements that identify the recipe and the client, as given in the [[EHLO advertised URL|forwarding request]]:
* the ''recipe-ID'',
* a valid ''recipe-KEY'', and
* the ''agreement-ID''.

The recipe-ID and the agreement-ID unambiguously identify the relevant (target) recipient address(es). The recipe-KEY authenticates the client.

The next element in the body of the request may have a local name of ''get'' or ''set'', according to the type of request that the client posts. In the following, we describe the meaning of the data. The format will have to be worked out so as to allow, for each keyword associated with a ''get'' or ''set'' verb, a list of values, or ''named-index=value'' pairs. Example keywords are as follows:

* ''DNSBL'', a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
* ''SPF'', an array of boolean reject/accept values, one for each possible SPF result, and
* ''flags'', the '''enabled''' and '''non-disclosure''' values as mentioned [[forwarding recipe#Policy considerations|here]].

The ''recipe-KEY'' itself can be changed by the client, for security reasons. The client usually is the ''final MTA''; however, it may in turn forward messages under a further agreement. That is to say, the client may also be a Mediator. In that case, it must ask for, and obtain, additional receipt-KEYs that it will eventually return to final MTAs, so that they can access senders recursively.

For static recipes and completed agreements, the server must honor a request to ''get forwarders'', that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators. This is where the additional receipt-KEYs mentioned in the previous paragraph are returned. The ''forwarders'' keyword is going to be get-only, in the sense that ''set forwarders'' is not going to be supported: The final MTA will have to access each upstream host in order to learn or change policy settings.

In addition, ''forwarder-ID'', ''password'', ''[[completion URL]]'' and ''determination'' are set-only elements that must be set once, before the agreement is completed. The server may refuse to change its forwarder-ID or the completion URL afterward. The password is already expired when it is being set, which forces the use of the completion URL. Setting a void password equates to saying that the old one is expired. The ''determination'' must be set if the client does not set ''forwarder-ID'', ''password'', and ''completion URL'': it is a human readable text explaining why the client acted the way it did.

Finally, besides ''get'' and ''set'', a ''delete'' element may be posted to a completed agreement. It means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned (See [[#Server response|below]].)

=== Credentials and cryptographic support ===
When using HTTPS transport, the client should download and verify the certificate being provided. This is done a couple of layers below SOAP. The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.

An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts and tools. However, a ''Web of Trust'', à la PGP, seems better suited for this task. MTAs already publish cryptographic keys. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.

An MTA who has been honoring a forwarding agreement for some time, might ask its peer to certify that. The receiving MTA should have collected enough data to conclude that a forwarder is not a spammer, before signing.

An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it knows to be a trustworthy peer. The number of known signers would then be a valid complement of the relevant ''whois'' information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust (with suitable coefficients) might result in a reliable algorithm. However, that may complicate this specification more than what it is worth.

=== Server response ===
The server must fail for any unrecognized or invalid identification, in case the client comes in with a nonexistent receipt-ID, or invalid recipient address(es). The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar errors possibly due to lack of synchronization.

For valid ''get'' requests, the server must include a list of values that the client may modify in a subsequent ''set'' request.

Positive responses should always include the status of the agreement. It remains ''underway'' until a forwarder-ID/password pair and completion URL have not been set. Afterward it switches to ''pending completion'' until a valid password has been set by visiting the URL thus provided. Eventually it will be ''complete''. The server should react to a determination setting, that is the client's refusal to grant the agreement, by deleting all data, as if receiving a ''delete'' verb.

It goes without saying that, after it has acknowledged a given set of options, the server must honor those settings. Effective changes are not necessarily synchronous, but must be carried out withing a reasonable amount of hours. If this URL is being serviced by a different machine than the one that hosts the recipe, and the latter is currently down or disconnected, fulfilling the request has to be delayed. Obviously, mail must not be relayed by an MTA which is down or disconnected. Settings must take place within a few hours after that MTA gets back into operations.

A delete request, or a determination not to grant a forwarding agreement, implies to '''remove all occurrences of the relevant email address(es)''' from the forwarding recipe. For static recipes, that means to delete the recipe ''and'' the mailbox; users might just disable forwarding otherwise. The status of the agreement switches to ''deleted'', and the server shall continue to acknowledge valid requests about it, until the delete operation is actually completed. That is to say, the recipe data and keys used to service this URL must be deleted ''after'' the recipe data that make forwarding possible. Thereafter, requests will fail.</text>
    <sha1>a3f2b44f67af8fcfd38a13367f2914a82bf662a5</sha1>
  </revision>
</page>
<page arvcontinue="20081206153830|1455">
  <title>completion URL</title>
  <ns>0</ns>
  <id>22</id>
  <revision>
    <id>1502</id>
    <timestamp>2008-12-28T16:14:38Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>new page</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="3738" xml:space="preserve">The '''completion URL''' formally completes a [[forwarding agreement]] handshake by setting a valid password; in addition, it serves those facets of the negotiation that imply setting parameters on the server, e.g. the Feedback Loop address, and agreement termination. The server of the URL is an MTA that has negotiated an agreement. The client is an MTA configured with the [[forwarding recipe]] that the agreement is linked with.

The client is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Client and server are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL allows the client to set various types of data. It may coincide or not with the [[EHLO advertised URL]], depending on the server convenience. If it coincides, it must obviously accept forwarding requests, but they are not considered here.

Every request to this URL must post the elements that authenticate the client and identify the agreement:
* ''Forwarder-ID'',
* a valid (although possibly expired) ''password'', and
* the ''agreement-ID''.

A request may contain one or more of the following data.

==== password ====
A password may be expired as far as SMTP Authentication is concerned, but still valid for setting a new password using this URL. Changing the password should be the first client concern in this case. The client may decide at any time that the password should be changed, after receiving a 535 ''Authentication credentials invalid'' response from the relevant SMTP server, or after its password has been reset at its policy negotiation URL.

The server may reject weak passwords.

==== Feedback Loop email address ====
The server must accept this address, and forward there any report associated with mail sent under the relevant forwarding agreement. The server should have an automated reporting mechanism; if it doesn't, this address can still be used to send complaints manually, in the correct format. The ''Abuse Feedback Reporting Format'' (ARF)[http://tools.ietf.org/html/draft-shafranovich-feedback-report-05] is assumed.

The server may reject invalid email addresses.

==== policy negotiation URL ====
The policy negotiation URL is used to recognize forwarders in case of new forwarding requests, thus it should not change often. Changing it for the given agreement may result in changing it for all agreements stipulated with the same forwarder-ID, according to the database design at the server. If not, the client should change the URL also for all existing agreements ''before'' requiring new ones. If not, its requests for new agreements may be rejected or generate a different forwarder-ID.

The server may reject invalid URLs.

==== agreement termination ====
Mailing lists can be canceled, and static recipes can be deleted, on the client's own initiative. When that happens, it should be notified using this URL. The notification should be done ''after'' the deletion. The server may verify the deletion at the negotiation URL. The client may give this notification after the server issued a ''delete'' command at the negotiation URL. If the client issues a deletion on its own initiative, it is its responsibility to also terminate any relevant forwarding chain upstream.

=== Server response ===
The server must fail in case of bad identification or authentication.

Positive server responses must include a list of the accepted settings. In case of URL changes, it must specify if the URL has been changed for more than one agreement.

Successfully setting a password for the first time concludes the handshake, and the forwarding agreement is considered undertaken.</text>
    <sha1>e99b7b5c4680a1952f1a4babba63b4ac461d12c3</sha1>
  </revision>
  <revision>
    <id>1503</id>
    <parentid>1502</parentid>
    <timestamp>2008-12-28T16:57:55Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Semantics */ the password is related to the agreement-ID</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4297" xml:space="preserve">The '''completion URL''' formally completes a [[forwarding agreement]] handshake by setting a valid password; in addition, it serves those facets of the negotiation that imply setting parameters on the server, e.g. the Feedback Loop address, and agreement termination. The server of the URL is an MTA that has negotiated an agreement. The client is an MTA configured with the [[forwarding recipe]] that the agreement is linked with.

The client is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Client and server are also respectively named ''Transmitter'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL allows the client to set various types of data. It may coincide or not with the [[EHLO advertised URL]], depending on the server convenience. If it coincides, it must obviously accept forwarding requests, but they are not considered here.

Every request to this URL must post the elements that authenticate the client and identify the agreement:
* ''forwarder-ID'',
* the ''agreement-ID'', and
* a valid (although possibly expired) ''password''.

A request may contain one or more of the following data.

==== password ====
A password may be expired as far as SMTP Authentication is concerned, but still valid for setting a new password using this URL. Changing the password should be the first client concern in this case. The client may decide at any time that the password should be changed, after receiving a 535 ''Authentication credentials invalid'' response from the relevant SMTP server, or after its password has been reset at its policy negotiation URL.

Notice that a forwarder may have multiple agreements with the server. Each agreement has its own password.

The server may reject weak passwords.

==== Feedback Loop email address ====
The server must accept this address, and forward there any report associated with mail sent under the relevant forwarding agreement. The server should have an automated reporting mechanism; if it doesn't, this address can still be used to send complaints manually, in the correct format. The ''Abuse Feedback Reporting Format'' (ARF)[http://tools.ietf.org/html/draft-shafranovich-feedback-report-05] is assumed.

The server may reject invalid email addresses.

==== policy negotiation URL ====
The policy negotiation URL is used to recognize forwarders in case of new forwarding requests, thus it should not change. However, organizational changes may require that host names and/or locations be changed. Changing it for the given agreement may result in changing it for all agreements stipulated with the same forwarder-ID, according to the database design at the server. If not, the client should change the URL also for all existing agreements ''before'' requiring new ones. If not, its requests for new agreements may be rejected or generate a different forwarder-ID.

Forwarding agreements are not transferable, and the forwarder-ID cannot be changed. Hence, changing the negotiation URL is not meant for that. In case a whole line of business is merged or transferred, changing the URL may serve to cope with the relevant organizational changes.

The server may refuse to change the URL. In that case, a forwarder should terminate existing agreements and enter new ones.

==== agreement termination ====
Mailing lists can be canceled, and static recipes can be deleted, on the client's own initiative. When that happens, it should be notified using this URL. The notification should be done ''after'' the deletion. The server may verify the deletion at the negotiation URL. The client may give this notification after the server issued a ''delete'' command at the negotiation URL. If the client issues a deletion on its own initiative, it is its responsibility to also terminate any relevant forwarding chain upstream.

=== Server response ===
The server must fail in case of bad identification or authentication.

Positive server responses must include a list of the accepted settings. In case of URL changes, it must specify if the URL has been changed for more than one agreement.

Successfully setting a password for the first time concludes the handshake, and the forwarding agreement is considered undertaken.</text>
    <sha1>20a6770ee3c0a606522693aada1c89e0a0297174</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>forwarding agreement</title>
  <ns>0</ns>
  <id>11</id>
  <revision>
    <id>1505</id>
    <parentid>1497</parentid>
    <timestamp>2008-12-28T17:33:47Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>minor adjustments</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7859" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and a password, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==

=== agreement-ID ===
The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for SMTP Authentication. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

=== forwarder-ID ===
The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

=== category ===
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''. The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. A tentative list of categories is as follows:
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, and
* backup MX.

Sometimes static recipes can be edited using web forms or other remote mechanisms. The key difference is that static recipes allow a single user with enough permissions to edit multiple addresses at once, e.g. by providing a comma separated list. Dynamic recipes allow to independently add/delete single addresses without even letting the relevant user know whether there are more addresses on the list.

Mailing lists have a time-honored mechanism to subscribe/unsubscribe by email, web form management has been added on top of that, and the software designed to manage forwarding agreements may act compliantly. Any list that is not, strictly speaking, a ''mailing list'', is a newsletter.

The category is not supposed to change during an agreement's life-cycle, thus some of the above distinctions may be dropped.

=== user-ID ===
The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the completion URL and set a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP request/response pages under HTTPS transport. An advantage of SOAP is that it avoids having to specify any encoding, multiple lines syntax, and similar kind of stuff; experience published about NETCONF can be used as a guideline, see RFC 5381. HTTPS as a transport allows secure password exchange; in addition, the certificate and its signing authority can be taken into account when deciding to grant the agreement (but see also [[policy negotiation URL#Credentials and cryptographic support|Credentials and cryptographic support]].)

We define the following:
* the [[EHLO advertised URL]],
* the [[policy negotiation URL]] at the forwarder's, and
* the [[completion URL]].

The first and last ones are served by the target MTA.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for each recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender's must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail addresses that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. Alternatively, static recipes may be disabled causing the relevant server to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SASL mechanism being used with SMTP Authentication, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>cd8bbcc9327f184afb276a397b993388fea35295</sha1>
  </revision>
  <revision>
    <id>1514</id>
    <parentid>1505</parentid>
    <timestamp>2009-01-16T18:15:00Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* URLs */ add Lisa's link on SOAP</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7976" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and a password, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==

=== agreement-ID ===
The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for SMTP Authentication. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

=== forwarder-ID ===
The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

=== category ===
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''. The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. A tentative list of categories is as follows:
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, and
* backup MX.

Sometimes static recipes can be edited using web forms or other remote mechanisms. The key difference is that static recipes allow a single user with enough permissions to edit multiple addresses at once, e.g. by providing a comma separated list. Dynamic recipes allow to independently add/delete single addresses without even letting the relevant user know whether there are more addresses on the list.

Mailing lists have a time-honored mechanism to subscribe/unsubscribe by email, web form management has been added on top of that, and the software designed to manage forwarding agreements may act compliantly. Any list that is not, strictly speaking, a ''mailing list'', is a newsletter.

The category is not supposed to change during an agreement's life-cycle, thus some of the above distinctions may be dropped.

=== user-ID ===
The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the completion URL and set a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP request/response pages under HTTPS transport. An advantage of SOAP is that it avoids having to specify any encoding, multiple lines syntax, and similar kind of stuff; experience published about NETCONF can be used as a guideline, see RFC 5381. Lisa Dusseault does not agree, though[http://nih.blogspot.com/2008/09/ive-been-asked-lot-about-use-of-soap-in.html]. HTTPS as a transport allows secure password exchange; in addition, the certificate and its signing authority can be taken into account when deciding to grant the agreement (but see also [[policy negotiation URL#Credentials and cryptographic support|Credentials and cryptographic support]].)

We define the following:
* the [[EHLO advertised URL]],
* the [[policy negotiation URL]] at the forwarder's, and
* the [[completion URL]].

The first and last ones are served by the target MTA.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for each recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender's must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail addresses that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. Alternatively, static recipes may be disabled causing the relevant server to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SASL mechanism being used with SMTP Authentication, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>25b1f5e2ddc5b47ec1573141d4341f0a7025c79e</sha1>
  </revision>
  <revision>
    <id>1525</id>
    <parentid>1514</parentid>
    <timestamp>2009-03-01T11:16:30Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* URLs */ Remove Lisa's surname, since it's not in her blog either</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7966" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and a password, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==

=== agreement-ID ===
The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for SMTP Authentication. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

=== forwarder-ID ===
The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

=== category ===
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''. The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. A tentative list of categories is as follows:
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, and
* backup MX.

Sometimes static recipes can be edited using web forms or other remote mechanisms. The key difference is that static recipes allow a single user with enough permissions to edit multiple addresses at once, e.g. by providing a comma separated list. Dynamic recipes allow to independently add/delete single addresses without even letting the relevant user know whether there are more addresses on the list.

Mailing lists have a time-honored mechanism to subscribe/unsubscribe by email, web form management has been added on top of that, and the software designed to manage forwarding agreements may act compliantly. Any list that is not, strictly speaking, a ''mailing list'', is a newsletter.

The category is not supposed to change during an agreement's life-cycle, thus some of the above distinctions may be dropped.

=== user-ID ===
The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the completion URL and set a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP request/response pages under HTTPS transport. An advantage of SOAP is that it avoids having to specify any encoding, multiple lines syntax, and similar kind of stuff; experience published about NETCONF can be used as a guideline, see RFC 5381. Lisa does not agree, though[http://nih.blogspot.com/2008/09/ive-been-asked-lot-about-use-of-soap-in.html]. HTTPS as a transport allows secure password exchange; in addition, the certificate and its signing authority can be taken into account when deciding to grant the agreement (but see also [[policy negotiation URL#Credentials and cryptographic support|Credentials and cryptographic support]].)

We define the following:
* the [[EHLO advertised URL]],
* the [[policy negotiation URL]] at the forwarder's, and
* the [[completion URL]].

The first and last ones are served by the target MTA.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for each recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender's must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail addresses that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. Alternatively, static recipes may be disabled causing the relevant server to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SASL mechanism being used with SMTP Authentication, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>60dda407fbf821d107887be7837686aadd68b769</sha1>
  </revision>
  <revision>
    <id>1532</id>
    <parentid>1525</parentid>
    <timestamp>2009-05-29T14:31:28Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* URLs */ Add REST</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8281" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and a password, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==

=== agreement-ID ===
The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for SMTP Authentication. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

=== forwarder-ID ===
The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

=== category ===
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''. The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. A tentative list of categories is as follows:
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, and
* backup MX.

Sometimes static recipes can be edited using web forms or other remote mechanisms. The key difference is that static recipes allow a single user with enough permissions to edit multiple addresses at once, e.g. by providing a comma separated list. Dynamic recipes allow to independently add/delete single addresses without even letting the relevant user know whether there are more addresses on the list.

Mailing lists have a time-honored mechanism to subscribe/unsubscribe by email, web form management has been added on top of that, and the software designed to manage forwarding agreements may act compliantly. Any list that is not, strictly speaking, a ''mailing list'', is a newsletter.

The category is not supposed to change during an agreement's life-cycle, thus some of the above distinctions may be dropped.

=== user-ID ===
The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the completion URL and set a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP or REST request/response pages under HTTPS transport. An advantage of using an existing framework is that it avoids having to specify any encoding, multiple lines syntax, and similar kind of stuff; experience published about NETCONF can be used as a guideline, see RFC 5381. Lisa does not like SOAP[http://nih.blogspot.com/2008/09/ive-been-asked-lot-about-use-of-soap-in.html], REST looks simpler[http://blog.feedly.com/2009/03/03/jsonrest-vs-xmlsoap/]. (See also [http://www.ietf.org/proceedings/07dec/slides/xmltut-1.pdf Using XML in Internet Protocols].) HTTPS as a transport allows secure password exchange; in addition, the certificate and its signing authority can be taken into account when deciding to grant the agreement (but see also [[policy negotiation URL#Credentials and cryptographic support|Credentials and cryptographic support]].) SOAP has further security options and WS-* features, but for the time being they don't seem necessary.

We define the following URLs:
* the [[EHLO advertised URL]],
* the [[policy negotiation URL]] at the forwarder's, and
* the [[completion URL]].

The first and last ones are served by the target MTA.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for each recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender's must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail addresses that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. Alternatively, static recipes may be disabled causing the relevant server to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SASL mechanism being used with SMTP Authentication, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>9ceed7d6ec45c45ac4f61d70556efe881bff0357</sha1>
  </revision>
  <revision>
    <id>1533</id>
    <parentid>1532</parentid>
    <timestamp>2009-10-08T13:38:50Z</timestamp>
    <contributor>
      <username>Test</username>
      <id>3</id>
    </contributor>
    <comment>/* category */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8353" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and a password, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==

=== agreement-ID ===
The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for SMTP Authentication. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

=== forwarder-ID ===
The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

=== category ===
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''. The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. A tentative list of categories is as follows:
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, 
* [http://www.research-service.com/custom-essay-writing.html custom essay]
* backup MX.

Sometimes static recipes can be edited using web forms or other remote mechanisms. The key difference is that static recipes allow a single user with enough permissions to edit multiple addresses at once, e.g. by providing a comma separated list. Dynamic recipes allow to independently add/delete single addresses without even letting the relevant user know whether there are more addresses on the list.

Mailing lists have a time-honored mechanism to subscribe/unsubscribe by email, web form management has been added on top of that, and the software designed to manage forwarding agreements may act compliantly. Any list that is not, strictly speaking, a ''mailing list'', is a newsletter.

The category is not supposed to change during an agreement's life-cycle, thus some of the above distinctions may be dropped.

=== user-ID ===
The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the completion URL and set a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP or REST request/response pages under HTTPS transport. An advantage of using an existing framework is that it avoids having to specify any encoding, multiple lines syntax, and similar kind of stuff; experience published about NETCONF can be used as a guideline, see RFC 5381. Lisa does not like SOAP[http://nih.blogspot.com/2008/09/ive-been-asked-lot-about-use-of-soap-in.html], REST looks simpler[http://blog.feedly.com/2009/03/03/jsonrest-vs-xmlsoap/]. (See also [http://www.ietf.org/proceedings/07dec/slides/xmltut-1.pdf Using XML in Internet Protocols].) HTTPS as a transport allows secure password exchange; in addition, the certificate and its signing authority can be taken into account when deciding to grant the agreement (but see also [[policy negotiation URL#Credentials and cryptographic support|Credentials and cryptographic support]].) SOAP has further security options and WS-* features, but for the time being they don't seem necessary.

We define the following URLs:
* the [[EHLO advertised URL]],
* the [[policy negotiation URL]] at the forwarder's, and
* the [[completion URL]].

The first and last ones are served by the target MTA.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for each recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender's must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail addresses that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. Alternatively, static recipes may be disabled causing the relevant server to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SASL mechanism being used with SMTP Authentication, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>7a2b70facb4255c5192d691cd0fb86490ba8ee79</sha1>
  </revision>
  <revision>
    <id>1534</id>
    <parentid>1533</parentid>
    <timestamp>2009-10-08T16:03:31Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Undo revision 1533 by [[Special:Contributions/JohnSteves|JohnSteves]] ([[User talk:JohnSteves|Talk]])</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8281" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and a password, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==

=== agreement-ID ===
The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for SMTP Authentication. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

=== forwarder-ID ===
The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

=== category ===
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''. The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. A tentative list of categories is as follows:
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, and
* backup MX.

Sometimes static recipes can be edited using web forms or other remote mechanisms. The key difference is that static recipes allow a single user with enough permissions to edit multiple addresses at once, e.g. by providing a comma separated list. Dynamic recipes allow to independently add/delete single addresses without even letting the relevant user know whether there are more addresses on the list.

Mailing lists have a time-honored mechanism to subscribe/unsubscribe by email, web form management has been added on top of that, and the software designed to manage forwarding agreements may act compliantly. Any list that is not, strictly speaking, a ''mailing list'', is a newsletter.

The category is not supposed to change during an agreement's life-cycle, thus some of the above distinctions may be dropped.

=== user-ID ===
The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the completion URL and set a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP or REST request/response pages under HTTPS transport. An advantage of using an existing framework is that it avoids having to specify any encoding, multiple lines syntax, and similar kind of stuff; experience published about NETCONF can be used as a guideline, see RFC 5381. Lisa does not like SOAP[http://nih.blogspot.com/2008/09/ive-been-asked-lot-about-use-of-soap-in.html], REST looks simpler[http://blog.feedly.com/2009/03/03/jsonrest-vs-xmlsoap/]. (See also [http://www.ietf.org/proceedings/07dec/slides/xmltut-1.pdf Using XML in Internet Protocols].) HTTPS as a transport allows secure password exchange; in addition, the certificate and its signing authority can be taken into account when deciding to grant the agreement (but see also [[policy negotiation URL#Credentials and cryptographic support|Credentials and cryptographic support]].) SOAP has further security options and WS-* features, but for the time being they don't seem necessary.

We define the following URLs:
* the [[EHLO advertised URL]],
* the [[policy negotiation URL]] at the forwarder's, and
* the [[completion URL]].

The first and last ones are served by the target MTA.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for each recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender's must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail addresses that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. Alternatively, static recipes may be disabled causing the relevant server to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SASL mechanism being used with SMTP Authentication, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>9ceed7d6ec45c45ac4f61d70556efe881bff0357</sha1>
  </revision>
  <revision>
    <id>1552</id>
    <parentid>1534</parentid>
    <timestamp>2010-07-21T09:59:02Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>Reverted edits by [[Special:Contributions/Ale|Ale]] ([[User talk:Ale|Talk]]) to last revision by [[User:JohnSteves|JohnSteves]]</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8353" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and a password, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==

=== agreement-ID ===
The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for SMTP Authentication. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

=== forwarder-ID ===
The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

=== category ===
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''. The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. A tentative list of categories is as follows:
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter, 
* [http://www.research-service.com/custom-essay-writing.html custom essay]
* backup MX.

Sometimes static recipes can be edited using web forms or other remote mechanisms. The key difference is that static recipes allow a single user with enough permissions to edit multiple addresses at once, e.g. by providing a comma separated list. Dynamic recipes allow to independently add/delete single addresses without even letting the relevant user know whether there are more addresses on the list.

Mailing lists have a time-honored mechanism to subscribe/unsubscribe by email, web form management has been added on top of that, and the software designed to manage forwarding agreements may act compliantly. Any list that is not, strictly speaking, a ''mailing list'', is a newsletter.

The category is not supposed to change during an agreement's life-cycle, thus some of the above distinctions may be dropped.

=== user-ID ===
The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the completion URL and set a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP or REST request/response pages under HTTPS transport. An advantage of using an existing framework is that it avoids having to specify any encoding, multiple lines syntax, and similar kind of stuff; experience published about NETCONF can be used as a guideline, see RFC 5381. Lisa does not like SOAP[http://nih.blogspot.com/2008/09/ive-been-asked-lot-about-use-of-soap-in.html], REST looks simpler[http://blog.feedly.com/2009/03/03/jsonrest-vs-xmlsoap/]. (See also [http://www.ietf.org/proceedings/07dec/slides/xmltut-1.pdf Using XML in Internet Protocols].) HTTPS as a transport allows secure password exchange; in addition, the certificate and its signing authority can be taken into account when deciding to grant the agreement (but see also [[policy negotiation URL#Credentials and cryptographic support|Credentials and cryptographic support]].) SOAP has further security options and WS-* features, but for the time being they don't seem necessary.

We define the following URLs:
* the [[EHLO advertised URL]],
* the [[policy negotiation URL]] at the forwarder's, and
* the [[completion URL]].

The first and last ones are served by the target MTA.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for each recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender's must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail addresses that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. Alternatively, static recipes may be disabled causing the relevant server to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SASL mechanism being used with SMTP Authentication, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>7a2b70facb4255c5192d691cd0fb86490ba8ee79</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>Talk:EHLO advertised URL</title>
  <ns>1</ns>
  <id>23</id>
  <revision>
    <id>1506</id>
    <timestamp>2008-12-29T00:52:58Z</timestamp>
    <contributor>
      <username>Macquigg</username>
      <id>2</id>
    </contributor>
    <comment>Corrected terminology</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="849" xml:space="preserve">Original Text:
: Client and server are also respectively named Transmitter and MDA according to MHS[2] terminology.

 |--- Sender's Network ---|           |-------- Recipient's Network ---------|
                                 /
 Author ==&gt; MSA/Transmitter --&gt; / --&gt; Receiver/Forwarder ~~&gt; MDA ==&gt; Recipient
                               /
                            Border

The client is a Forwarder, not a Transmitter.  A Transmitter has no relationship with a Receiver, whereas a Forwarder has an indirect relationship with an MDA, due to the direct relationship both have with the Recipient.  This is important, because we are counting on that relationship to establish the forwarding agreement.  Without this special relationship, you have an entirely different problem - the general problem of establishing trust between unrelated parties.</text>
    <sha1>38bd222e660e63c787baba701304b2281c8aef73</sha1>
  </revision>
  <revision>
    <id>1507</id>
    <parentid>1506</parentid>
    <timestamp>2008-12-29T06:05:38Z</timestamp>
    <contributor>
      <username>Macquigg</username>
      <id>2</id>
    </contributor>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="1120" xml:space="preserve">=== Terminology Correction ===

Original Text:
: Client and server are also respectively named Transmitter and MDA according to MHS[2] terminology.

Model of system we are discussing:

 |--- Sender's Network ---|           |-------- Recipient's Network ---------|
                                 /
 Author ==&gt; MSA/Transmitter --&gt; / --&gt; Receiver/Forwarder ~~&gt; MDA ==&gt; Recipient
                               /
                            Border

The client is a Forwarder, not a Transmitter.  A Transmitter has no relationship with a Receiver, whereas a Forwarder has an indirect relationship with an MDA, due to the direct relationship both have with the Recipient.  This is important, because we are counting on that relationship to establish the forwarding agreement.  Without this special relationship, you have an entirely different problem - the general problem of establishing trust between unrelated parties.

Establishing trust in a forwarding agreement requires only one simple check.  Ask the Recipient if the agreement is OK.

This same misuse of the term Transmitter should be fixed on other pages as well.</text>
    <sha1>0e8068dd6adca4893c50fbadf556a66327a09228</sha1>
  </revision>
  <revision>
    <id>1512</id>
    <parentid>1507</parentid>
    <timestamp>2008-12-29T10:43:18Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Terms, Ask the Recipient</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2150" xml:space="preserve">=== Terminology Correction ===

Original Text:
: Client and server are also respectively named Transmitter and MDA according to MHS[2] terminology.

Model of system we are discussing:

 |--- Sender's Network ---|           |-------- Recipient's Network ---------|
                                 /
 Author ==&gt; MSA/Transmitter --&gt; / --&gt; Receiver/Forwarder ~~&gt; MDA ==&gt; Recipient
                               /
                            Border

The client is a Forwarder, not a Transmitter.  A Transmitter has no relationship with a Receiver, whereas a Forwarder has an indirect relationship with an MDA, due to the direct relationship both have with the Recipient.  This is important, because we are counting on that relationship to establish the forwarding agreement.  Without this special relationship, you have an entirely different problem - the general problem of establishing trust between unrelated parties.

Establishing trust in a forwarding agreement requires only one simple check.  Ask the Recipient if the agreement is OK.

This same misuse of the term Transmitter should be fixed on other pages as well.

==== Terms ====
Thank you for spotting this. ''Forwarder'' is a much more natural term in this case, and it obviously is on the receiver side of the [[boundary]]. However, for this content page in particular, the client is not ''yet'' a Forwarder. I resorted to ''candidate Forwarder''.

==== Ask the Recipient ====
Asking the Recipient is going to be slow, as it involves human intervention. In that case, the message at hand will be relayed as usual.

For regular legit cases, the user already opted in and possibly acknowledged a mail address check. If we could go so far as to intercept double checks, then there is no reason to ask again, and we could grant access right away. However, that complicates things further. For ''known'' forwarders, the MDA should just grant the agreement.

On the other hand, an ESP should provide a web page for setting email options, and the Recipient can go there to delete the agreement, possibly declaring that it was not legitimate. (The latter should affect the forwarder's reputation.)</text>
    <sha1>0257641014611fba0fe63963b0a88f244b88c4a7</sha1>
  </revision>
  <revision>
    <id>1513</id>
    <parentid>1512</parentid>
    <timestamp>2008-12-30T20:27:20Z</timestamp>
    <contributor>
      <username>Macquigg</username>
      <id>2</id>
    </contributor>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4453" xml:space="preserve">=== Terminology Correction ===

Original Text:
: Client and server are also respectively named Transmitter and MDA according to MHS[2] terminology.

Model of system we are discussing:

 |--- Sender's Network ---|           |-------- Recipient's Network ---------|
                                 /
 Author ==&gt; MSA/Transmitter --&gt; / --&gt; Receiver/Forwarder ~~&gt; MDA ==&gt; Recipient
                               /
                            Border

The client is a Forwarder, not a Transmitter.  A Transmitter has no relationship with a Receiver, whereas a Forwarder has an indirect relationship with an MDA, due to the direct relationship both have with the Recipient.  This is important, because we are counting on that relationship to establish the forwarding agreement.  Without this special relationship, you have an entirely different problem - the general problem of establishing trust between unrelated parties.

Establishing trust in a forwarding agreement requires only one simple check.  Ask the Recipient if the agreement is OK.

This same misuse of the term Transmitter should be fixed on other pages as well.
 --[[User:Macquigg|Macquigg]] 20:27, 30 December 2008 (GMT)
==== Terms ====
Thank you for spotting this. ''Forwarder'' is a much more natural term in this case, and it obviously is on the receiver side of the [[boundary]]. However, for this content page in particular, the client is not ''yet'' a Forwarder. I resorted to ''candidate Forwarder''.
:We need to distinguish between "boundary" and Border.  Boundary can mean any line between two Actors (ADMDs).  The Border is a special boundary, the only one between unrelated Actors.--[[User:Macquigg|Macquigg]] 20:27, 30 December 2008 (GMT)

==== Ask the Recipient ====
Asking the Recipient is going to be slow, as it involves human intervention. In that case, the message at hand will be relayed as usual.
: I wouldn't worry about the delay.  Setting up forwarding for most recipients is a very rare event, and it should be done carefully.  Getting confirmation from the MDA, as well as precise feedback on exactly how the forwarding is being set up, is important for the recipient.  The confirmation message can also include instructions and warnings about forwarded spam, etc.

:The fundamental purpose of having a forwarding relationship is to allow mail from an otherwise untrusted source to be whitelisted for one recipient.  Google.com may be sending spam to the entire planet, but if I have an account there and I want my mail forwarded to my mailbox at Yahoo, I will tolerate that spam (or complain to Google).  Other Yahoo customers will not tolerate Google's spam.

:We may have a fundamental misunderstanding on what Forwarding is all about.  To me it means a relationship set up by the Recipient.  This can be done without any involvement by the Forwarder or MDA, but it may help to have that involvement when the Recipient is not properly trained (almost always).  Keeping the Recipient "in the loop" is important.  I would go even further than an initial confirmation message.  I would send a reminder once per month.--[[User:Macquigg|Macquigg]] 20:27, 30 December 2008 (GMT)

For regular legit cases, the user already opted in and possibly acknowledged a mail address check. 
: I must be missing something.  Aren't we talking about setting up forwarding?  Once a forwarding relationship has been established, it should not be necessary to do anything special, other than whitelist the mail from this forwarder to that recipient. --[[User:Macquigg|Macquigg]] 20:27, 30 December 2008 (GMT)

If we could go so far as to intercept double checks, then there is no reason to ask again, and we could grant access right away. However, that complicates things further. For ''known'' forwarders, the MDA should just grant the agreement.
:I don't like having a separate mechanism for "known" good Forwarders.  If we had such a mechanism, it should allow whitelisting *all* mail from that Forwarder.  In other words, there is no need to distinguish a Forwarder from a Transmitter.  The responsible domain is either trusted or not, and its mail is either whitelisted or spam filtered.--[[User:Macquigg|Macquigg]] 20:27, 30 December 2008 (GMT)

On the other hand, an ESP should provide a web page for setting email options, and the Recipient can go there to delete the agreement, possibly declaring that it was not legitimate. (The latter should affect the forwarder's reputation.)</text>
    <sha1>235f56008a09d6a3903a722e580aa6a3dd1c2989</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>EHLO advertised URL</title>
  <ns>0</ns>
  <id>20</id>
  <revision>
    <id>1508</id>
    <parentid>1499</parentid>
    <timestamp>2008-12-29T10:02:34Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>fix Transmitter =&gt; Forwarder</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4353" xml:space="preserve">The '''EHLO advertised URL''' receives ''forwarding requests''; that is, requests for establishing a [[forwarding agreement]]. The server of the URL is an MTA ready to grant such agreements. The client is an MTA configured with a [[forwarding recipe]], that is willing to relay related messages under an agreement. As its name says, this URL is advertised by the server in its EHLO response.

The client is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Client and server may be respectively called a ''candidate Forwarder'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
Visiting this URL constitutes the first of the three steps provided for setting up a forwarding agreement. The URL itself may change as needed, since it is only used once for each request. The clients posts (or ''sends'', if using SMTP transport) the essential data that defines the agreement:

* The ''recipe-ID'' as known by the client.
* The ''recipe-KEY'', an authentication code for negotiating the agreement.
* A human readable ''recipe name''.
* The ''recipient address(es)''; the target addresses at the server's. The server will transform these into the agreement's [[forwarding agreement#user-ID|user-ID]], according to its internal data structures.
* The agreement's ''category'', one of the [[forwarding agreement#category|types defined]].
* The [[policy negotiation URL]], where the server will in turn pay a visit.
* Optionally, the ''forwarder-ID''; this is the identity of the client as known by the server, in case the client has already entered into an agreement with the same server.
* Optionally, any evidence that may be relevant. For example, the IP address and GMT date of the user's opt-in.

The tentative list above is meant to comprise all the data to fully describe the forwarder's intentions.

The recipe-ID and the recipe-KEY will be used by the server to identify itself when it will, in turn, pay a visit to the supplied policy negotiation URL. By contrast, the ''recipe name'' is what will be visible to users and should meaningfully identify the forwarding. The name may be the incoming address at the client's in the case of static forwarding, or the newsletter or mailing list name.

The client is not authenticated at this stage. If a ''forwarder-ID'' is supplied, the server should verify that the policy negotiation URL coincides with the one already stored for that ID. If not recognized, the server must not use the supplied ''forwarder-ID'' for making decisions, but may use it as a hint to synthesize the content of the corresponding field of the agreement.

The server should carry out any verification that it wishes. If supplied evidence includes IP addresses that the server can verify, it should do so before they possibly change and before relevant log files are obliterated. Notice that, except for evidence, no IP addresses are involved.

=== Server response ===
The server accepts the request by creating an ''agreement-ID'' and communicating it to the client. The agreement-ID is a key to all related data, including the recipient address(es). The recipe-ID may be used as a prefix to create agreement-IDs that relate to the same remote recipe.

The server may take several paths. If the server can estimate that the agreement is likely to be granted within a few hours, it should say so. That information is needed by the client in order to decide how to queue the message at hand.

If any verification fails, the server may reject the current request and let the client try again with a better one. If the request mentions an agreement that has already been established, the server should just signal that this is a spoof retrial.

If the server requires human intervention, or other lengthy process that may eventually result in negotiating a policy and granting the agreement, it should signal so. In this case the client marks the recipe as having an agreement underway, and continues to relay as usual meanwhile. It is the server responsibility to eventually visit the policy negotiation URL, possibly for the sole purpose of canceling the pending request.

Notice that it may be convenient for the server to grant an agreement to a known spammer for the sole purpose of rejecting any mail identified that way.</text>
    <sha1>a7dcb1587d55b228cfa8d66886daa6496291af2a</sha1>
  </revision>
  <revision>
    <id>1511</id>
    <parentid>1508</parentid>
    <timestamp>2008-12-29T10:37:57Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Server response */ temporary failures for multiple mailboxes</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4844" xml:space="preserve">The '''EHLO advertised URL''' receives ''forwarding requests''; that is, requests for establishing a [[forwarding agreement]]. The server of the URL is an MTA ready to grant such agreements. The client is an MTA configured with a [[forwarding recipe]], that is willing to relay related messages under an agreement. As its name says, this URL is advertised by the server in its EHLO response.

The client is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Client and server may be respectively called a ''candidate Forwarder'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
Visiting this URL constitutes the first of the three steps provided for setting up a forwarding agreement. The URL itself may change as needed, since it is only used once for each request. The clients posts (or ''sends'', if using SMTP transport) the essential data that defines the agreement:

* The ''recipe-ID'' as known by the client.
* The ''recipe-KEY'', an authentication code for negotiating the agreement.
* A human readable ''recipe name''.
* The ''recipient address(es)''; the target addresses at the server's. The server will transform these into the agreement's [[forwarding agreement#user-ID|user-ID]], according to its internal data structures.
* The agreement's ''category'', one of the [[forwarding agreement#category|types defined]].
* The [[policy negotiation URL]], where the server will in turn pay a visit.
* Optionally, the ''forwarder-ID''; this is the identity of the client as known by the server, in case the client has already entered into an agreement with the same server.
* Optionally, any evidence that may be relevant. For example, the IP address and GMT date of the user's opt-in.

The tentative list above is meant to comprise all the data to fully describe the forwarder's intentions.

The recipe-ID and the recipe-KEY will be used by the server to identify itself when it will, in turn, pay a visit to the supplied policy negotiation URL. By contrast, the ''recipe name'' is what will be visible to users and should meaningfully identify the forwarding. The name may be the incoming address at the client's in the case of static forwarding, or the newsletter or mailing list name.

The client is not authenticated at this stage. If a ''forwarder-ID'' is supplied, the server should verify that the policy negotiation URL coincides with the one already stored for that ID. If not recognized, the server must not use the supplied ''forwarder-ID'' for making decisions, but may use it as a hint to synthesize the content of the corresponding field of the agreement.

The server should carry out any verification that it wishes. If supplied evidence includes IP addresses that the server can verify, it should do so before they possibly change and before relevant log files are obliterated. Notice that, except for evidence, no IP addresses are involved.

=== Server response ===
The server accepts the request by creating an ''agreement-ID'' and communicating it to the client. The agreement-ID is a key to all related data, including the recipient address(es). The recipe-ID may be used as a prefix to create agreement-IDs that relate to the same remote recipe.

The server may take several paths. If the server can estimate that the agreement is likely to be granted within a few hours, it should say so. That information is needed by the client in order to decide how to queue the message at hand.

In case of multiple recipients, if the server cannot handle them uniformly it may respond with a temporary failure that includes a list of one or more addresses that can be handled uniformly and are likely to generate a positive response. In general, there should be only one address. However, some cases of static forwarding to multiple mailboxes might be accepted. (It is advisable to forward to a single mailbox that in turn explodes locally to the desired targets, if at all possible.)

If any verification fails, the server may reject the current request and let the client try again with a better one. If the request mentions an agreement that has already been established, the server should just signal that this is a spoof retrial.

If the server requires human intervention, or other lengthy process that may eventually result in negotiating a policy and granting the agreement, it should signal so. In this case the client marks the recipe as having an agreement underway, and continues to relay as usual meanwhile. It is the server responsibility to eventually visit the policy negotiation URL, possibly for the sole purpose of canceling the pending request.

Notice that it may be convenient for the server to grant an agreement to a known spammer for the sole purpose of rejecting any mail identified that way.</text>
    <sha1>40c53972f8fc6b0492a283183685e57ef8185194</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>policy negotiation URL</title>
  <ns>0</ns>
  <id>21</id>
  <revision>
    <id>1509</id>
    <parentid>1504</parentid>
    <timestamp>2008-12-29T10:03:33Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>fix Transmitter =&gt; Forwarder</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8421" xml:space="preserve">The '''policy negotiation URL''' is where a [[forwarding agreement]] is established and maintained. The server of the URL is the forwarding MTA that applied for, and possibly obtained, an agreement associated with a specific [[forwarding recipe]]. The client is the MTA who granted (or is going to grant) the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.

Please note that the client and server roles are exchanged with respect to the other two handshake URLs. The server is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Server and client are also respectively named ''Forwarded'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes as well as database design.

Every request to this URL must post the elements that identify the recipe and the client, as given in the [[EHLO advertised URL|forwarding request]]:
* the ''recipe-ID'',
* a valid ''recipe-KEY'', and
* the ''agreement-ID''.

The recipe-ID and the agreement-ID unambiguously identify the relevant (target) recipient address(es). The recipe-KEY authenticates the client.

The next element in the body of the request may have a local name of ''get'' or ''set'', according to the type of request that the client posts. In the following, we describe the meaning of the data. The format will have to be worked out so as to allow, for each keyword associated with a ''get'' or ''set'' verb, a list of values, or ''named-index=value'' pairs. Example keywords are as follows:

* ''DNSBL'', a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
* ''SPF'', an array of boolean reject/accept values, one for each possible SPF result, and
* ''flags'', the '''enabled''' and '''non-disclosure''' values as mentioned [[forwarding recipe#Policy considerations|here]].

The ''recipe-KEY'' itself can be changed by the client, for security reasons. The client usually is the ''final MTA''; however, it may in turn forward messages under a further agreement. That is to say, the client may also be a Mediator. In that case, it must ask for, and obtain, additional receipt-KEYs that it will eventually return to final MTAs, so that they can access senders recursively.

For static recipes and completed agreements, the server must honor a request to ''get forwarders'', that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators. This is where the additional receipt-KEYs mentioned in the previous paragraph are returned. The ''forwarders'' keyword is going to be get-only, in the sense that ''set forwarders'' is not going to be supported: The final MTA will have to access each upstream host in order to learn or change policy settings.

In addition, ''forwarder-ID'', ''password'', ''[[completion URL]]'' and ''determination'' are set-only elements that must be set once, before the agreement is completed. The server may refuse to change its forwarder-ID or the completion URL afterward. The password is already expired when it is being set, which forces the use of the completion URL. Setting a void password equates to saying that the old one is expired. The ''determination'' must be set if the client does not set ''forwarder-ID'', ''password'', and ''completion URL'': it is a human readable text explaining why the client acted the way it did.

Finally, besides ''get'' and ''set'', a ''delete'' element may be posted to a completed agreement. It means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned (See [[#Server response|below]].)

=== Credentials and cryptographic support ===
When using HTTPS transport, the client should download and verify the certificate being provided. This is done a couple of layers below SOAP. The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.

An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts and tools. However, a ''Web of Trust'', à la PGP, seems better suited for this task. MTAs already publish cryptographic keys. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.

An MTA who has been honoring a forwarding agreement for some time, might ask its peer to certify that. The receiving MTA should have collected enough data to conclude that a forwarder is not a spammer, before signing.

An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it knows to be a trustworthy peer. The number of known signers would then be a valid complement of the relevant ''whois'' information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust (with suitable coefficients) might result in a reliable algorithm. However, that may complicate this specification more than what it is worth.

=== Server response ===
The server must fail for any unrecognized or invalid identification, in case the client comes in with a nonexistent receipt-ID, or invalid recipient address(es). The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar errors possibly due to lack of synchronization.

For valid ''get'' requests, the server must include a list of values that the client may modify in a subsequent ''set'' request.

Positive responses should always include the status of the agreement. It remains ''underway'' until a forwarder-ID/password pair and completion URL have not been set. Afterward it switches to ''pending completion'' until a valid password has been set by visiting the URL thus provided. Eventually it will be ''complete''. The server should react to a determination setting, that is the client's refusal to grant the agreement, by deleting all data, as if receiving a ''delete'' verb.

It goes without saying that, after it has acknowledged a given set of options, the server must honor those settings. Effective changes are not necessarily synchronous, but must be carried out withing a reasonable amount of hours. If this URL is being serviced by a different machine than the one that hosts the recipe, and the latter is currently down or disconnected, fulfilling the request has to be delayed. Obviously, mail must not be relayed by an MTA which is down or disconnected. Settings must take place within a few hours after that MTA gets back into operations.

A delete request, or a determination not to grant a forwarding agreement, implies to '''remove all occurrences of the relevant email address(es)''' from the forwarding recipe. For static recipes, that means to delete the recipe ''and'' the mailbox; users might just disable forwarding otherwise. The status of the agreement switches to ''deleted'', and the server shall continue to acknowledge valid requests about it, until the delete operation is actually completed. That is to say, the recipe data and keys used to service this URL must be deleted ''after'' the recipe data that make forwarding possible. Thereafter, requests will fail.</text>
    <sha1>ebfa80b9b2223525bdb887d62c70793cf42fcb83</sha1>
  </revision>
  <revision>
    <id>1524</id>
    <parentid>1509</parentid>
    <timestamp>2009-02-17T16:28:57Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Credentials and cryptographic support */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8568" xml:space="preserve">The '''policy negotiation URL''' is where a [[forwarding agreement]] is established and maintained. The server of the URL is the forwarding MTA that applied for, and possibly obtained, an agreement associated with a specific [[forwarding recipe]]. The client is the MTA who granted (or is going to grant) the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.

Please note that the client and server roles are exchanged with respect to the other two handshake URLs. The server is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Server and client are also respectively named ''Forwarded'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes as well as database design.

Every request to this URL must post the elements that identify the recipe and the client, as given in the [[EHLO advertised URL|forwarding request]]:
* the ''recipe-ID'',
* a valid ''recipe-KEY'', and
* the ''agreement-ID''.

The recipe-ID and the agreement-ID unambiguously identify the relevant (target) recipient address(es). The recipe-KEY authenticates the client.

The next element in the body of the request may have a local name of ''get'' or ''set'', according to the type of request that the client posts. In the following, we describe the meaning of the data. The format will have to be worked out so as to allow, for each keyword associated with a ''get'' or ''set'' verb, a list of values, or ''named-index=value'' pairs. Example keywords are as follows:

* ''DNSBL'', a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
* ''SPF'', an array of boolean reject/accept values, one for each possible SPF result, and
* ''flags'', the '''enabled''' and '''non-disclosure''' values as mentioned [[forwarding recipe#Policy considerations|here]].

The ''recipe-KEY'' itself can be changed by the client, for security reasons. The client usually is the ''final MTA''; however, it may in turn forward messages under a further agreement. That is to say, the client may also be a Mediator. In that case, it must ask for, and obtain, additional receipt-KEYs that it will eventually return to final MTAs, so that they can access senders recursively.

For static recipes and completed agreements, the server must honor a request to ''get forwarders'', that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators. This is where the additional receipt-KEYs mentioned in the previous paragraph are returned. The ''forwarders'' keyword is going to be get-only, in the sense that ''set forwarders'' is not going to be supported: The final MTA will have to access each upstream host in order to learn or change policy settings.

In addition, ''forwarder-ID'', ''password'', ''[[completion URL]]'' and ''determination'' are set-only elements that must be set once, before the agreement is completed. The server may refuse to change its forwarder-ID or the completion URL afterward. The password is already expired when it is being set, which forces the use of the completion URL. Setting a void password equates to saying that the old one is expired. The ''determination'' must be set if the client does not set ''forwarder-ID'', ''password'', and ''completion URL'': it is a human readable text explaining why the client acted the way it did.

Finally, besides ''get'' and ''set'', a ''delete'' element may be posted to a completed agreement. It means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned (See [[#Server response|below]].)

=== Credentials and cryptographic support ===
When using HTTPS transport, the client should download and verify the certificate being provided. This is done a couple of layers below SOAP. (It can be done ''within'' SOAP if we throw in more [[wp:Web Services|WS-*]] stuff. However, requiring that may make the protocol overly complex.) The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.

An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts and tools. However, a ''Web of Trust'', à la PGP, seems better suited for this task. MTAs already publish cryptographic keys. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.

An MTA who has been honoring a forwarding agreement for some time, might ask its peer to certify that. The receiving MTA should have collected enough data to conclude that a forwarder is not a spammer, before signing.

An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it knows to be a trustworthy peer. The number of known signers would then be a valid complement of the relevant ''whois'' information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust (with suitable coefficients) might result in a reliable algorithm. However, that may complicate this specification more than what it is worth.

=== Server response ===
The server must fail for any unrecognized or invalid identification, in case the client comes in with a nonexistent receipt-ID, or invalid recipient address(es). The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar errors possibly due to lack of synchronization.

For valid ''get'' requests, the server must include a list of values that the client may modify in a subsequent ''set'' request.

Positive responses should always include the status of the agreement. It remains ''underway'' until a forwarder-ID/password pair and completion URL have not been set. Afterward it switches to ''pending completion'' until a valid password has been set by visiting the URL thus provided. Eventually it will be ''complete''. The server should react to a determination setting, that is the client's refusal to grant the agreement, by deleting all data, as if receiving a ''delete'' verb.

It goes without saying that, after it has acknowledged a given set of options, the server must honor those settings. Effective changes are not necessarily synchronous, but must be carried out withing a reasonable amount of hours. If this URL is being serviced by a different machine than the one that hosts the recipe, and the latter is currently down or disconnected, fulfilling the request has to be delayed. Obviously, mail must not be relayed by an MTA which is down or disconnected. Settings must take place within a few hours after that MTA gets back into operations.

A delete request, or a determination not to grant a forwarding agreement, implies to '''remove all occurrences of the relevant email address(es)''' from the forwarding recipe. For static recipes, that means to delete the recipe ''and'' the mailbox; users might just disable forwarding otherwise. The status of the agreement switches to ''deleted'', and the server shall continue to acknowledge valid requests about it, until the delete operation is actually completed. That is to say, the recipe data and keys used to service this URL must be deleted ''after'' the recipe data that make forwarding possible. Thereafter, requests will fail.</text>
    <sha1>b1454e78567dac4ad6a1091e6d70c86f99779a50</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>completion URL</title>
  <ns>0</ns>
  <id>22</id>
  <revision>
    <id>1510</id>
    <parentid>1503</parentid>
    <timestamp>2008-12-29T10:04:09Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>fix Transmitter =&gt; Forwarder</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4295" xml:space="preserve">The '''completion URL''' formally completes a [[forwarding agreement]] handshake by setting a valid password; in addition, it serves those facets of the negotiation that imply setting parameters on the server, e.g. the Feedback Loop address, and agreement termination. The server of the URL is an MTA that has negotiated an agreement. The client is an MTA configured with the [[forwarding recipe]] that the agreement is linked with.

The client is a ''Mediator'' according to Internet Mail Architecture[http://tools.ietf.org/html/draft-crocker-email-arch-11]. Client and server are also respectively named ''Forwarder'' and ''MDA'' according to MHS[http://open-mail.org/MHSmodel.html] terminology.

== Semantics ==
This URL allows the client to set various types of data. It may coincide or not with the [[EHLO advertised URL]], depending on the server convenience. If it coincides, it must obviously accept forwarding requests, but they are not considered here.

Every request to this URL must post the elements that authenticate the client and identify the agreement:
* ''forwarder-ID'',
* the ''agreement-ID'', and
* a valid (although possibly expired) ''password''.

A request may contain one or more of the following data.

==== password ====
A password may be expired as far as SMTP Authentication is concerned, but still valid for setting a new password using this URL. Changing the password should be the first client concern in this case. The client may decide at any time that the password should be changed, after receiving a 535 ''Authentication credentials invalid'' response from the relevant SMTP server, or after its password has been reset at its policy negotiation URL.

Notice that a forwarder may have multiple agreements with the server. Each agreement has its own password.

The server may reject weak passwords.

==== Feedback Loop email address ====
The server must accept this address, and forward there any report associated with mail sent under the relevant forwarding agreement. The server should have an automated reporting mechanism; if it doesn't, this address can still be used to send complaints manually, in the correct format. The ''Abuse Feedback Reporting Format'' (ARF)[http://tools.ietf.org/html/draft-shafranovich-feedback-report-05] is assumed.

The server may reject invalid email addresses.

==== policy negotiation URL ====
The policy negotiation URL is used to recognize forwarders in case of new forwarding requests, thus it should not change. However, organizational changes may require that host names and/or locations be changed. Changing it for the given agreement may result in changing it for all agreements stipulated with the same forwarder-ID, according to the database design at the server. If not, the client should change the URL also for all existing agreements ''before'' requiring new ones. If not, its requests for new agreements may be rejected or generate a different forwarder-ID.

Forwarding agreements are not transferable, and the forwarder-ID cannot be changed. Hence, changing the negotiation URL is not meant for that. In case a whole line of business is merged or transferred, changing the URL may serve to cope with the relevant organizational changes.

The server may refuse to change the URL. In that case, a forwarder should terminate existing agreements and enter new ones.

==== agreement termination ====
Mailing lists can be canceled, and static recipes can be deleted, on the client's own initiative. When that happens, it should be notified using this URL. The notification should be done ''after'' the deletion. The server may verify the deletion at the negotiation URL. The client may give this notification after the server issued a ''delete'' command at the negotiation URL. If the client issues a deletion on its own initiative, it is its responsibility to also terminate any relevant forwarding chain upstream.

=== Server response ===
The server must fail in case of bad identification or authentication.

Positive server responses must include a list of the accepted settings. In case of URL changes, it must specify if the URL has been changed for more than one agreement.

Successfully setting a password for the first time concludes the handshake, and the forwarding agreement is considered undertaken.</text>
    <sha1>0e8442df204b989443eec813c4b362630b81a557</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>privacy laws</title>
  <ns>0</ns>
  <id>17</id>
  <revision>
    <id>1515</id>
    <parentid>1463</parentid>
    <timestamp>2009-01-23T18:56:12Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* An example */ new section</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="3537" xml:space="preserve">By '''privacy laws''' we mean any of the legal frameworks that regulate information privacy in the USA, EU, and several national countries. Although not exactly uniform, the existing bodies of rules tend to converge toward certain principles aimed at protecting people against undiscriminated usage of collected ''personally identifiable information'', a.k.a. ''personal data''.

== Freedom in the digital era ==
Advancements in electronics allow to exercise pervasive and widespread control on what the people do. Digital control can provide for appealing means for implementing commercial practices on unprecedentedly wide scales. While customers used to be able to guard against a shopkeeper foxiness by themselves, they are defenseless when confronted with large business enterprises who systematically exchange their customers' PI information with one another.

As it often happens during the transition from an era to the next, criteria and even laws that have been stipulated in times when their enforcement was provided by radically different means, may become questionable. The efforts undertaken thus far to define the legal terms and the issues implied by the new scenario, are the first chisel blows for establishing the future shape.

The Internet protocols that make this all possible, including SMTP, have necessarily been designed before it all began.

== Implementing the law ==
''Opt-in'' and ''opt-out'' are two key concept for regulating how commercial newsletters may be sent. The SMTP protocol talks about ''mailing lists'', not newsletters. Technically, they are the same thing, since the exact working of the subscribe and unsubscribe operations is not specified rigorously.

RFC 2369 mandates some headers with special URLs. The ''List-Unsubscribe'' header field contains the command to directly unsubscribe from the list. However, mail clients usually don't show it to the user. A possible reason for that uncooperative behavior may lay in the unknown nature of the command, that may expose the user to security risks if programmed by a malicious sender.

In addition, whatever method of subscribe or unsubscribe gets executed, users are given just a notice of the outcome of the operation, that they seldom save or print. The data remains at the lists owners', which makes it hard to take legal stances. There is no need to take legal actions, because legitimate senders always honor users commands; however, such tautological statements contribute to make ''spam'' a fuzzy term.

An email address is considered personally identifiable data. The agreement of its owner is required for storing and using that data. Its owner has the right to amend or delete it. It is the law. The [[solution proposed]] provides for a standard unsubscribe method, and provides for a copy of the users commands to be kept by their ESPs.

== An example ==
Alice used to work for example.com. When she left, she asked the postmaster to place a .forward file for her, in order to continue to receive personal mail. After a few years, only spam is being forwarded. She would like the forwarding recipe to be removed. However, the postmaster she knew also left the company.

Of course, she could make an official request to the company. That implies getting in touch with her former boss. However, she wouldn't like to call him. Possibly, for the same reasons that she left the company years ago.

Asking someone else to do something for us, is not the same as doing it directly. Does the term ''wiki'' teach anything in this respect?</text>
    <sha1>a5daa28ab4239343fcb038514f0b35e8db1039e1</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>File:Ale-dec2008.jpg</title>
  <ns>6</ns>
  <id>24</id>
  <revision>
    <id>1516</id>
    <timestamp>2009-01-28T11:43:46Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Me, portrayed by my wife during our winter holidays.</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="52" xml:space="preserve">Me, portrayed by my wife during our winter holidays.</text>
    <sha1>04a6bfadbc20c2cdd7480dc3224228e4649c4c4f</sha1>
  </revision>
  <revision>
    <id>1518</id>
    <parentid>1516</parentid>
    <timestamp>2009-01-28T17:46:44Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>uploaded a new version of "[[Image:Ale-dec2008.jpg]]": reloaded</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="52" xml:space="preserve">Me, portrayed by my wife during our winter holidays.</text>
    <sha1>04a6bfadbc20c2cdd7480dc3224228e4649c4c4f</sha1>
  </revision>
  <revision>
    <id>1520</id>
    <parentid>1518</parentid>
    <timestamp>2009-01-28T18:14:38Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>mention the place</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="82" xml:space="preserve">Me, portrayed by my wife during our winter holidays in [[wp:Welschnofen|Carezza]].</text>
    <sha1>fa4cc72b1625e5e2f381197bee8d543a272e80c7</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>User:Ale</title>
  <ns>2</ns>
  <id>25</id>
  <revision>
    <id>1517</id>
    <timestamp>2009-01-28T17:27:09Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>insert picture</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="56" xml:space="preserve">[[Image:Ale-dec2008.jpg|200px|thumb|left|alt 31Dec 2008]</text>
    <sha1>e3213e96a33c11c233bfe9c55a87521912f56f00</sha1>
  </revision>
  <revision>
    <id>1519</id>
    <parentid>1517</parentid>
    <timestamp>2009-01-28T18:07:43Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>some text</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="74" xml:space="preserve">[[Image:Ale-dec2008.jpg|thumb|center|400px|Alessandro Vesely, site admin]]</text>
    <sha1>7e75ff4cf82a0ac96648204bdb8de3762c3d6aa2</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>FixForwarding:Copyrights</title>
  <ns>4</ns>
  <id>2</id>
  <revision>
    <id>1521</id>
    <parentid>1410</parentid>
    <timestamp>2009-02-03T13:32:18Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>typo</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="746" xml:space="preserve">The content of this site is copyright of FixForwarding.org, and is available as stated below. This means that Authors agree to submit their contribution using such terms. In this respect, FixForwarding.org is an abstract entity that stands for the set of Authors who have contributed to the resulting "joint work".

Permission is granted to copy, distribute and/or modify the contents of this site under the terms of the [http://www.gnu.org/licenses/fdl-1.2.html#TOC1 GNU Free Documentation License, Version 1.2] or any later version published by the [http://www.fsf.org/ Free Software Foundation]; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.  A copy of the license can be seen following the links in this paragraph.</text>
    <sha1>3e4ea93eb0afabbca46bf145aee9bda96e459329</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>forwarding recipe</title>
  <ns>0</ns>
  <id>10</id>
  <revision>
    <id>1522</id>
    <parentid>1455</parentid>
    <timestamp>2009-02-03T13:35:51Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Static recipes */ fix tag</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6448" xml:space="preserve">A '''forwarding recipe''' is the procedural data by which a mail server can build a new envelope for an existing message before re-injecting it into the mail system. It includes the forwarded address that the original message bore, one or more new recipient addresses to whom the re-injected message is destined, and a policy. The policy determines the new envelope sender address, at least.

== Common forwarding recipes ==
=== Static recipes ===
Historically, recipes were written in [http://www.sendmail.org/ sendmail]'s &lt;code&gt;.forward&lt;/code&gt; files in a recipient's home directory, in order to elicit specific forwarding behavior from the server when a message is received at a given mailbox. Recipes have to be addressable by their forwarded address, so that the software can find any relevant recipe upon message reception. Obviously, the software that implements the SMTP server dictates the format that recipes have to comply. Depending on the implementation, the data that conceptually makes up a recipe may be spread among several files.

A pipe character (&lt;code&gt;|&lt;/code&gt;) in a &lt;code&gt;.forward&lt;/code&gt; file allows executing external programs. Similar concepts work for [http://www.qmail.org/man/man5/dot-qmail.html .qmail] and [http://www.courier-mta.org/dot-courier.html .courier]. A forwarding recipe may consist of
 &amp;nbsp;&lt;code&gt;| sendmail -f postmaster@example.org newrecipient@example.com&lt;/code&gt;

Notice that the forwarded address is implied by the location on disc where the recipe is written. In addition, the behavior triggered by messages bouncing to &lt;code&gt;postmaster@example.org&lt;/code&gt; is conceptually part of this recipe but is specified somewhere else.

=== Newsletters and mailing lists ===
Dynamic recipes are managed by specialized software. Such software has well defined schemata to precisely define what messages are forwarded to what addresses. A number of ''best practices'' documents exists that specify how to reliably send bulk mail, e.g. [http://mipassoc.org/spamops/index.html MIPAssoc]. In case the model proposed here will be adopted, it may be added to the list of things to do, but it will have to be done on a per-package basis.

=== Backup MXes ===
A backup MX also does forwarding. What is special in it, is that forwarding recipes are ''implicit''. See also [[boundary#Backup MXes]].

== Quest for agreement ==
A forwarding recipe introduces a new segment in the message path, which should be considered within the recipient's realm. In fact, the ''newrecipient'' address is [[wp:personally identifiable information]] of its owner, therefore its owner should have explicitly given a permission to use it in a certain way. That permission, also called ''opt-in'', is not routinely asked for. Even when it is, e.g. when subscribing to a mailing list, the relevant forwarding recipe is stored at the forwarding host only. [[Forwarding agreement]]s are proposed to obviate this limitation and let a forwarding recipe be known and acted upon by its owner, directly from the target host.

=== Envelope sender tweak ===
An easy technique to let the sending software know that a message is being forwarded is by changing the envelope sender to some special value that is only understood within the host/ADMD. For example&lt;code&gt;
 &amp;nbsp;| sendmail -f ff=&lt;i&gt;keyword&lt;/i&gt;=&lt;i&gt;param&lt;/i&gt;=postmaster@example.org newrecipient@example.com&lt;/code&gt;
The line above provides a keyword and a parameter for using an existing forwarding agreement, or start negotiating one. The sending software, upon seeing that the remote MX accepts the ''ff'' model, shall search a local database for a record corresponding to &lt;code&gt;newrecipient@example.com&lt;/code&gt;, the remote MX, and the keyword parameter. That record is considered a ''complement'' of the forwarding recipe.

If the record is found and contains an id/password for logging in, the sending software recovers the original envelope sender from the ''Return-Path'' header and forwards the message according to this model. For ongoing negotiations, the record may contain an indication to either queue the message or send it normally until the negotiation completes. Otherwise, the keyword and parameter can be used to load a configurated environment and launch the first step of the negotiation. In this case the return code indicates whether to queue the message or sending it normally.

Sending the message normally, which is also done in case the remote MX does not support ''FF'', implies using the default envelope sender, in this case &lt;code&gt;postmaster@example.org&lt;/code&gt;. The tweaked envelope sender never leaves the relevant host. However, it may be set on an internal host inside the same ADMD in case the existing forwarding recipe is not on a boundary host.

== Policy considerations ==
In its simplest form, a forwarding recipe may be difficult to manage. The complexity may increase depending on who and how can create mailboxes and recipes on the system, what spam filtering options are available, and spam reporting mechanisms.

On a small system where only the postmaster creates mailboxes and recipes, for example, a recipe as exemplified above may make sense. Upon receiving a delivery failure, the postmaster should decide whether to drop the recipe as the target address becomes unavailable or to advise the final recipient that the relevant mailbox is full. Larger systems will require to automate that behavior, therefore it becomes necessary to define exactly when and how each operation is performed. For example, a policy can specify a different behavior for a mailbox full situation if an alternative email address or, say, an SMS-enabled phone number are available for advising the final recipient.

A policy may contain various configuration items. It can provide for a number of different states, so that the server can stop receiving new mail in certain cases, possibly requiring that appropriate local responses are given, e.g.:
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;, or 
251  User not local; will forward to &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

Two flags are as follows:
* '''enabled''': mail is accepted, and
* '''non-disclosure''': the target address shall never be revealed.

As a forwarding recipe's policy is limited to local behavior, the ''non-disclosure'' flag affects the text in the server response, and do DSNs and MDNs as for lists. See RFC 3461, ''5.2.7.4 confidential forwarding addresses''; RFC 3798, ''6.2. Privacy''; RFC 3885.</text>
    <sha1>aed95f5a57add4f587b960e9e7fc2a6930381fc2</sha1>
  </revision>
  <revision>
    <id>1523</id>
    <parentid>1522</parentid>
    <timestamp>2009-02-03T13:37:04Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Envelope sender tweak */ fix tag</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6448" xml:space="preserve">A '''forwarding recipe''' is the procedural data by which a mail server can build a new envelope for an existing message before re-injecting it into the mail system. It includes the forwarded address that the original message bore, one or more new recipient addresses to whom the re-injected message is destined, and a policy. The policy determines the new envelope sender address, at least.

== Common forwarding recipes ==
=== Static recipes ===
Historically, recipes were written in [http://www.sendmail.org/ sendmail]'s &lt;code&gt;.forward&lt;/code&gt; files in a recipient's home directory, in order to elicit specific forwarding behavior from the server when a message is received at a given mailbox. Recipes have to be addressable by their forwarded address, so that the software can find any relevant recipe upon message reception. Obviously, the software that implements the SMTP server dictates the format that recipes have to comply. Depending on the implementation, the data that conceptually makes up a recipe may be spread among several files.

A pipe character (&lt;code&gt;|&lt;/code&gt;) in a &lt;code&gt;.forward&lt;/code&gt; file allows executing external programs. Similar concepts work for [http://www.qmail.org/man/man5/dot-qmail.html .qmail] and [http://www.courier-mta.org/dot-courier.html .courier]. A forwarding recipe may consist of
 &amp;nbsp;&lt;code&gt;| sendmail -f postmaster@example.org newrecipient@example.com&lt;/code&gt;

Notice that the forwarded address is implied by the location on disc where the recipe is written. In addition, the behavior triggered by messages bouncing to &lt;code&gt;postmaster@example.org&lt;/code&gt; is conceptually part of this recipe but is specified somewhere else.

=== Newsletters and mailing lists ===
Dynamic recipes are managed by specialized software. Such software has well defined schemata to precisely define what messages are forwarded to what addresses. A number of ''best practices'' documents exists that specify how to reliably send bulk mail, e.g. [http://mipassoc.org/spamops/index.html MIPAssoc]. In case the model proposed here will be adopted, it may be added to the list of things to do, but it will have to be done on a per-package basis.

=== Backup MXes ===
A backup MX also does forwarding. What is special in it, is that forwarding recipes are ''implicit''. See also [[boundary#Backup MXes]].

== Quest for agreement ==
A forwarding recipe introduces a new segment in the message path, which should be considered within the recipient's realm. In fact, the ''newrecipient'' address is [[wp:personally identifiable information]] of its owner, therefore its owner should have explicitly given a permission to use it in a certain way. That permission, also called ''opt-in'', is not routinely asked for. Even when it is, e.g. when subscribing to a mailing list, the relevant forwarding recipe is stored at the forwarding host only. [[Forwarding agreement]]s are proposed to obviate this limitation and let a forwarding recipe be known and acted upon by its owner, directly from the target host.

=== Envelope sender tweak ===
An easy technique to let the sending software know that a message is being forwarded is by changing the envelope sender to some special value that is only understood within the host/ADMD. For example
 &amp;nbsp;&lt;code&gt;| sendmail -f ff=&lt;i&gt;keyword&lt;/i&gt;=&lt;i&gt;param&lt;/i&gt;=postmaster@example.org newrecipient@example.com&lt;/code&gt;
The line above provides a keyword and a parameter for using an existing forwarding agreement, or start negotiating one. The sending software, upon seeing that the remote MX accepts the ''ff'' model, shall search a local database for a record corresponding to &lt;code&gt;newrecipient@example.com&lt;/code&gt;, the remote MX, and the keyword parameter. That record is considered a ''complement'' of the forwarding recipe.

If the record is found and contains an id/password for logging in, the sending software recovers the original envelope sender from the ''Return-Path'' header and forwards the message according to this model. For ongoing negotiations, the record may contain an indication to either queue the message or send it normally until the negotiation completes. Otherwise, the keyword and parameter can be used to load a configurated environment and launch the first step of the negotiation. In this case the return code indicates whether to queue the message or sending it normally.

Sending the message normally, which is also done in case the remote MX does not support ''FF'', implies using the default envelope sender, in this case &lt;code&gt;postmaster@example.org&lt;/code&gt;. The tweaked envelope sender never leaves the relevant host. However, it may be set on an internal host inside the same ADMD in case the existing forwarding recipe is not on a boundary host.

== Policy considerations ==
In its simplest form, a forwarding recipe may be difficult to manage. The complexity may increase depending on who and how can create mailboxes and recipes on the system, what spam filtering options are available, and spam reporting mechanisms.

On a small system where only the postmaster creates mailboxes and recipes, for example, a recipe as exemplified above may make sense. Upon receiving a delivery failure, the postmaster should decide whether to drop the recipe as the target address becomes unavailable or to advise the final recipient that the relevant mailbox is full. Larger systems will require to automate that behavior, therefore it becomes necessary to define exactly when and how each operation is performed. For example, a policy can specify a different behavior for a mailbox full situation if an alternative email address or, say, an SMS-enabled phone number are available for advising the final recipient.

A policy may contain various configuration items. It can provide for a number of different states, so that the server can stop receiving new mail in certain cases, possibly requiring that appropriate local responses are given, e.g.:
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;, or 
251  User not local; will forward to &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

Two flags are as follows:
* '''enabled''': mail is accepted, and
* '''non-disclosure''': the target address shall never be revealed.

As a forwarding recipe's policy is limited to local behavior, the ''non-disclosure'' flag affects the text in the server response, and do DSNs and MDNs as for lists. See RFC 3461, ''5.2.7.4 confidential forwarding addresses''; RFC 3798, ''6.2. Privacy''; RFC 3885.</text>
    <sha1>f37a69982bc5d85759a2491751baa34ffcb1d95d</sha1>
  </revision>
  <revision>
    <id>1526</id>
    <parentid>1523</parentid>
    <timestamp>2009-05-23T09:25:51Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Backup MXes */ link to ''Backup MX''</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6504" xml:space="preserve">A '''forwarding recipe''' is the procedural data by which a mail server can build a new envelope for an existing message before re-injecting it into the mail system. It includes the forwarded address that the original message bore, one or more new recipient addresses to whom the re-injected message is destined, and a policy. The policy determines the new envelope sender address, at least.

== Common forwarding recipes ==
=== Static recipes ===
Historically, recipes were written in [http://www.sendmail.org/ sendmail]'s &lt;code&gt;.forward&lt;/code&gt; files in a recipient's home directory, in order to elicit specific forwarding behavior from the server when a message is received at a given mailbox. Recipes have to be addressable by their forwarded address, so that the software can find any relevant recipe upon message reception. Obviously, the software that implements the SMTP server dictates the format that recipes have to comply. Depending on the implementation, the data that conceptually makes up a recipe may be spread among several files.

A pipe character (&lt;code&gt;|&lt;/code&gt;) in a &lt;code&gt;.forward&lt;/code&gt; file allows executing external programs. Similar concepts work for [http://www.qmail.org/man/man5/dot-qmail.html .qmail] and [http://www.courier-mta.org/dot-courier.html .courier]. A forwarding recipe may consist of
 &amp;nbsp;&lt;code&gt;| sendmail -f postmaster@example.org newrecipient@example.com&lt;/code&gt;

Notice that the forwarded address is implied by the location on disc where the recipe is written. In addition, the behavior triggered by messages bouncing to &lt;code&gt;postmaster@example.org&lt;/code&gt; is conceptually part of this recipe but is specified somewhere else.

=== Newsletters and mailing lists ===
Dynamic recipes are managed by specialized software. Such software has well defined schemata to precisely define what messages are forwarded to what addresses. A number of ''best practices'' documents exists that specify how to reliably send bulk mail, e.g. [http://mipassoc.org/spamops/index.html MIPAssoc]. In case the model proposed here will be adopted, it may be added to the list of things to do, but it will have to be done on a per-package basis.

=== Backup MXes ===
&lt;!-- TODO: add template {{main|Forwarding agreement}} --&gt;
''Main article: [[Backup MX]]''

A backup MX also does forwarding. What is special in it, is that forwarding recipes are ''implicit''.

== Quest for agreement ==
A forwarding recipe introduces a new segment in the message path, which should be considered within the recipient's realm. In fact, the ''newrecipient'' address is [[wp:personally identifiable information]] of its owner, therefore its owner should have explicitly given a permission to use it in a certain way. That permission, also called ''opt-in'', is not routinely asked for. Even when it is, e.g. when subscribing to a mailing list, the relevant forwarding recipe is stored at the forwarding host only. [[Forwarding agreement]]s are proposed to obviate this limitation and let a forwarding recipe be known and acted upon by its owner, directly from the target host.

=== Envelope sender tweak ===
An easy technique to let the sending software know that a message is being forwarded is by changing the envelope sender to some special value that is only understood within the host/ADMD. For example
 &amp;nbsp;&lt;code&gt;| sendmail -f ff=&lt;i&gt;keyword&lt;/i&gt;=&lt;i&gt;param&lt;/i&gt;=postmaster@example.org newrecipient@example.com&lt;/code&gt;
The line above provides a keyword and a parameter for using an existing forwarding agreement, or start negotiating one. The sending software, upon seeing that the remote MX accepts the ''ff'' model, shall search a local database for a record corresponding to &lt;code&gt;newrecipient@example.com&lt;/code&gt;, the remote MX, and the keyword parameter. That record is considered a ''complement'' of the forwarding recipe.

If the record is found and contains an id/password for logging in, the sending software recovers the original envelope sender from the ''Return-Path'' header and forwards the message according to this model. For ongoing negotiations, the record may contain an indication to either queue the message or send it normally until the negotiation completes. Otherwise, the keyword and parameter can be used to load a configurated environment and launch the first step of the negotiation. In this case the return code indicates whether to queue the message or sending it normally.

Sending the message normally, which is also done in case the remote MX does not support ''FF'', implies using the default envelope sender, in this case &lt;code&gt;postmaster@example.org&lt;/code&gt;. The tweaked envelope sender never leaves the relevant host. However, it may be set on an internal host inside the same ADMD in case the existing forwarding recipe is not on a boundary host.

== Policy considerations ==
In its simplest form, a forwarding recipe may be difficult to manage. The complexity may increase depending on who and how can create mailboxes and recipes on the system, what spam filtering options are available, and spam reporting mechanisms.

On a small system where only the postmaster creates mailboxes and recipes, for example, a recipe as exemplified above may make sense. Upon receiving a delivery failure, the postmaster should decide whether to drop the recipe as the target address becomes unavailable or to advise the final recipient that the relevant mailbox is full. Larger systems will require to automate that behavior, therefore it becomes necessary to define exactly when and how each operation is performed. For example, a policy can specify a different behavior for a mailbox full situation if an alternative email address or, say, an SMS-enabled phone number are available for advising the final recipient.

A policy may contain various configuration items. It can provide for a number of different states, so that the server can stop receiving new mail in certain cases, possibly requiring that appropriate local responses are given, e.g.:
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;, or 
251  User not local; will forward to &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

Two flags are as follows:
* '''enabled''': mail is accepted, and
* '''non-disclosure''': the target address shall never be revealed.

As a forwarding recipe's policy is limited to local behavior, the ''non-disclosure'' flag affects the text in the server response, and do DSNs and MDNs as for lists. See RFC 3461, ''5.2.7.4 confidential forwarding addresses''; RFC 3798, ''6.2. Privacy''; RFC 3885.</text>
    <sha1>8b3eca6d84f698bc37acdbdea8501a6e45c73645</sha1>
  </revision>
  <revision>
    <id>1548</id>
    <parentid>1526</parentid>
    <timestamp>2010-07-20T21:28:29Z</timestamp>
    <contributor>
      <username>Test</username>
      <id>3</id>
    </contributor>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6562" xml:space="preserve">A '''forwarding recipe''' is the procedural data by which a mail server can build a new envelope for an existing message before re-injecting it into the mail system creating a [http://www.superiorpapers.com/ essay writing]. It includes the forwarded address that the original message bore, one or more new recipient addresses to whom the re-injected message is destined, and a policy. The policy determines the new envelope sender address, at least.

== Common forwarding recipes ==
=== Static recipes ===
Historically, recipes were written in [http://www.sendmail.org/ sendmail]'s &lt;code&gt;.forward&lt;/code&gt; files in a recipient's home directory, in order to elicit specific forwarding behavior from the server when a message is received at a given mailbox. Recipes have to be addressable by their forwarded address, so that the software can find any relevant recipe upon message reception. Obviously, the software that implements the SMTP server dictates the format that recipes have to comply. Depending on the implementation, the data that conceptually makes up a recipe may be spread among several files.

A pipe character (&lt;code&gt;|&lt;/code&gt;) in a &lt;code&gt;.forward&lt;/code&gt; file allows executing external programs. Similar concepts work for [http://www.qmail.org/man/man5/dot-qmail.html .qmail] and [http://www.courier-mta.org/dot-courier.html .courier]. A forwarding recipe may consist of
 &amp;nbsp;&lt;code&gt;| sendmail -f postmaster@example.org newrecipient@example.com&lt;/code&gt;

Notice that the forwarded address is implied by the location on disc where the recipe is written. In addition, the behavior triggered by messages bouncing to &lt;code&gt;postmaster@example.org&lt;/code&gt; is conceptually part of this recipe but is specified somewhere else.

=== Newsletters and mailing lists ===
Dynamic recipes are managed by specialized software. Such software has well defined schemata to precisely define what messages are forwarded to what addresses. A number of ''best practices'' documents exists that specify how to reliably send bulk mail, e.g. [http://mipassoc.org/spamops/index.html MIPAssoc]. In case the model proposed here will be adopted, it may be added to the list of things to do, but it will have to be done on a per-package basis.

=== Backup MXes ===
&lt;!-- TODO: add template {{main|Forwarding agreement}} --&gt;
''Main article: [[Backup MX]]''

A backup MX also does forwarding. What is special in it, is that forwarding recipes are ''implicit''.

== Quest for agreement ==
A forwarding recipe introduces a new segment in the message path, which should be considered within the recipient's realm. In fact, the ''newrecipient'' address is [[wp:personally identifiable information]] of its owner, therefore its owner should have explicitly given a permission to use it in a certain way. That permission, also called ''opt-in'', is not routinely asked for. Even when it is, e.g. when subscribing to a mailing list, the relevant forwarding recipe is stored at the forwarding host only. [[Forwarding agreement]]s are proposed to obviate this limitation and let a forwarding recipe be known and acted upon by its owner, directly from the target host.

=== Envelope sender tweak ===
An easy technique to let the sending software know that a message is being forwarded is by changing the envelope sender to some special value that is only understood within the host/ADMD. For example
 &amp;nbsp;&lt;code&gt;| sendmail -f ff=&lt;i&gt;keyword&lt;/i&gt;=&lt;i&gt;param&lt;/i&gt;=postmaster@example.org newrecipient@example.com&lt;/code&gt;
The line above provides a keyword and a parameter for using an existing forwarding agreement, or start negotiating one. The sending software, upon seeing that the remote MX accepts the ''ff'' model, shall search a local database for a record corresponding to &lt;code&gt;newrecipient@example.com&lt;/code&gt;, the remote MX, and the keyword parameter. That record is considered a ''complement'' of the forwarding recipe.

If the record is found and contains an id/password for logging in, the sending software recovers the original envelope sender from the ''Return-Path'' header and forwards the message according to this model. For ongoing negotiations, the record may contain an indication to either queue the message or send it normally until the negotiation completes. Otherwise, the keyword and parameter can be used to load a configurated environment and launch the first step of the negotiation. In this case the return code indicates whether to queue the message or sending it normally.

Sending the message normally, which is also done in case the remote MX does not support ''FF'', implies using the default envelope sender, in this case &lt;code&gt;postmaster@example.org&lt;/code&gt;. The tweaked envelope sender never leaves the relevant host. However, it may be set on an internal host inside the same ADMD in case the existing forwarding recipe is not on a boundary host.

== Policy considerations ==
In its simplest form, a forwarding recipe may be difficult to manage. The complexity may increase depending on who and how can create mailboxes and recipes on the system, what spam filtering options are available, and spam reporting mechanisms.

On a small system where only the postmaster creates mailboxes and recipes, for example, a recipe as exemplified above may make sense. Upon receiving a delivery failure, the postmaster should decide whether to drop the recipe as the target address becomes unavailable or to advise the final recipient that the relevant mailbox is full. Larger systems will require to automate that behavior, therefore it becomes necessary to define exactly when and how each operation is performed. For example, a policy can specify a different behavior for a mailbox full situation if an alternative email address or, say, an SMS-enabled phone number are available for advising the final recipient.

A policy may contain various configuration items. It can provide for a number of different states, so that the server can stop receiving new mail in certain cases, possibly requiring that appropriate local responses are given, e.g.:
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;, or 
251  User not local; will forward to &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

Two flags are as follows:
* '''enabled''': mail is accepted, and
* '''non-disclosure''': the target address shall never be revealed.

As a forwarding recipe's policy is limited to local behavior, the ''non-disclosure'' flag affects the text in the server response, and do DSNs and MDNs as for lists. See RFC 3461, ''5.2.7.4 confidential forwarding addresses''; RFC 3798, ''6.2. Privacy''; RFC 3885.</text>
    <sha1>ba67e5b94bc912679c4041b0e3c1c47904ec7dd7</sha1>
  </revision>
  <revision>
    <id>1549</id>
    <parentid>1548</parentid>
    <timestamp>2010-07-20T21:28:44Z</timestamp>
    <contributor>
      <username>Test</username>
      <id>3</id>
    </contributor>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6563" xml:space="preserve">A '''forwarding recipe''' is the procedural data by which a mail server can build a new envelope for an existing message before re-injecting it into the mail system creating an [http://www.superiorpapers.com/ essay writing]. It includes the forwarded address that the original message bore, one or more new recipient addresses to whom the re-injected message is destined, and a policy. The policy determines the new envelope sender address, at least.

== Common forwarding recipes ==
=== Static recipes ===
Historically, recipes were written in [http://www.sendmail.org/ sendmail]'s &lt;code&gt;.forward&lt;/code&gt; files in a recipient's home directory, in order to elicit specific forwarding behavior from the server when a message is received at a given mailbox. Recipes have to be addressable by their forwarded address, so that the software can find any relevant recipe upon message reception. Obviously, the software that implements the SMTP server dictates the format that recipes have to comply. Depending on the implementation, the data that conceptually makes up a recipe may be spread among several files.

A pipe character (&lt;code&gt;|&lt;/code&gt;) in a &lt;code&gt;.forward&lt;/code&gt; file allows executing external programs. Similar concepts work for [http://www.qmail.org/man/man5/dot-qmail.html .qmail] and [http://www.courier-mta.org/dot-courier.html .courier]. A forwarding recipe may consist of
 &amp;nbsp;&lt;code&gt;| sendmail -f postmaster@example.org newrecipient@example.com&lt;/code&gt;

Notice that the forwarded address is implied by the location on disc where the recipe is written. In addition, the behavior triggered by messages bouncing to &lt;code&gt;postmaster@example.org&lt;/code&gt; is conceptually part of this recipe but is specified somewhere else.

=== Newsletters and mailing lists ===
Dynamic recipes are managed by specialized software. Such software has well defined schemata to precisely define what messages are forwarded to what addresses. A number of ''best practices'' documents exists that specify how to reliably send bulk mail, e.g. [http://mipassoc.org/spamops/index.html MIPAssoc]. In case the model proposed here will be adopted, it may be added to the list of things to do, but it will have to be done on a per-package basis.

=== Backup MXes ===
&lt;!-- TODO: add template {{main|Forwarding agreement}} --&gt;
''Main article: [[Backup MX]]''

A backup MX also does forwarding. What is special in it, is that forwarding recipes are ''implicit''.

== Quest for agreement ==
A forwarding recipe introduces a new segment in the message path, which should be considered within the recipient's realm. In fact, the ''newrecipient'' address is [[wp:personally identifiable information]] of its owner, therefore its owner should have explicitly given a permission to use it in a certain way. That permission, also called ''opt-in'', is not routinely asked for. Even when it is, e.g. when subscribing to a mailing list, the relevant forwarding recipe is stored at the forwarding host only. [[Forwarding agreement]]s are proposed to obviate this limitation and let a forwarding recipe be known and acted upon by its owner, directly from the target host.

=== Envelope sender tweak ===
An easy technique to let the sending software know that a message is being forwarded is by changing the envelope sender to some special value that is only understood within the host/ADMD. For example
 &amp;nbsp;&lt;code&gt;| sendmail -f ff=&lt;i&gt;keyword&lt;/i&gt;=&lt;i&gt;param&lt;/i&gt;=postmaster@example.org newrecipient@example.com&lt;/code&gt;
The line above provides a keyword and a parameter for using an existing forwarding agreement, or start negotiating one. The sending software, upon seeing that the remote MX accepts the ''ff'' model, shall search a local database for a record corresponding to &lt;code&gt;newrecipient@example.com&lt;/code&gt;, the remote MX, and the keyword parameter. That record is considered a ''complement'' of the forwarding recipe.

If the record is found and contains an id/password for logging in, the sending software recovers the original envelope sender from the ''Return-Path'' header and forwards the message according to this model. For ongoing negotiations, the record may contain an indication to either queue the message or send it normally until the negotiation completes. Otherwise, the keyword and parameter can be used to load a configurated environment and launch the first step of the negotiation. In this case the return code indicates whether to queue the message or sending it normally.

Sending the message normally, which is also done in case the remote MX does not support ''FF'', implies using the default envelope sender, in this case &lt;code&gt;postmaster@example.org&lt;/code&gt;. The tweaked envelope sender never leaves the relevant host. However, it may be set on an internal host inside the same ADMD in case the existing forwarding recipe is not on a boundary host.

== Policy considerations ==
In its simplest form, a forwarding recipe may be difficult to manage. The complexity may increase depending on who and how can create mailboxes and recipes on the system, what spam filtering options are available, and spam reporting mechanisms.

On a small system where only the postmaster creates mailboxes and recipes, for example, a recipe as exemplified above may make sense. Upon receiving a delivery failure, the postmaster should decide whether to drop the recipe as the target address becomes unavailable or to advise the final recipient that the relevant mailbox is full. Larger systems will require to automate that behavior, therefore it becomes necessary to define exactly when and how each operation is performed. For example, a policy can specify a different behavior for a mailbox full situation if an alternative email address or, say, an SMS-enabled phone number are available for advising the final recipient.

A policy may contain various configuration items. It can provide for a number of different states, so that the server can stop receiving new mail in certain cases, possibly requiring that appropriate local responses are given, e.g.:
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;, or 
251  User not local; will forward to &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

Two flags are as follows:
* '''enabled''': mail is accepted, and
* '''non-disclosure''': the target address shall never be revealed.

As a forwarding recipe's policy is limited to local behavior, the ''non-disclosure'' flag affects the text in the server response, and do DSNs and MDNs as for lists. See RFC 3461, ''5.2.7.4 confidential forwarding addresses''; RFC 3798, ''6.2. Privacy''; RFC 3885.</text>
    <sha1>d1a9a8f3217b5dbb387669e08e821db0bb4b00f8</sha1>
  </revision>
  <revision>
    <id>1550</id>
    <parentid>1549</parentid>
    <timestamp>2010-07-21T08:44:11Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Undo revision 1549 by [[Special:Contributions/Meryl20|Meryl20]] ([[User talk:Meryl20|Talk]])</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6562" xml:space="preserve">A '''forwarding recipe''' is the procedural data by which a mail server can build a new envelope for an existing message before re-injecting it into the mail system creating a [http://www.superiorpapers.com/ essay writing]. It includes the forwarded address that the original message bore, one or more new recipient addresses to whom the re-injected message is destined, and a policy. The policy determines the new envelope sender address, at least.

== Common forwarding recipes ==
=== Static recipes ===
Historically, recipes were written in [http://www.sendmail.org/ sendmail]'s &lt;code&gt;.forward&lt;/code&gt; files in a recipient's home directory, in order to elicit specific forwarding behavior from the server when a message is received at a given mailbox. Recipes have to be addressable by their forwarded address, so that the software can find any relevant recipe upon message reception. Obviously, the software that implements the SMTP server dictates the format that recipes have to comply. Depending on the implementation, the data that conceptually makes up a recipe may be spread among several files.

A pipe character (&lt;code&gt;|&lt;/code&gt;) in a &lt;code&gt;.forward&lt;/code&gt; file allows executing external programs. Similar concepts work for [http://www.qmail.org/man/man5/dot-qmail.html .qmail] and [http://www.courier-mta.org/dot-courier.html .courier]. A forwarding recipe may consist of
 &amp;nbsp;&lt;code&gt;| sendmail -f postmaster@example.org newrecipient@example.com&lt;/code&gt;

Notice that the forwarded address is implied by the location on disc where the recipe is written. In addition, the behavior triggered by messages bouncing to &lt;code&gt;postmaster@example.org&lt;/code&gt; is conceptually part of this recipe but is specified somewhere else.

=== Newsletters and mailing lists ===
Dynamic recipes are managed by specialized software. Such software has well defined schemata to precisely define what messages are forwarded to what addresses. A number of ''best practices'' documents exists that specify how to reliably send bulk mail, e.g. [http://mipassoc.org/spamops/index.html MIPAssoc]. In case the model proposed here will be adopted, it may be added to the list of things to do, but it will have to be done on a per-package basis.

=== Backup MXes ===
&lt;!-- TODO: add template {{main|Forwarding agreement}} --&gt;
''Main article: [[Backup MX]]''

A backup MX also does forwarding. What is special in it, is that forwarding recipes are ''implicit''.

== Quest for agreement ==
A forwarding recipe introduces a new segment in the message path, which should be considered within the recipient's realm. In fact, the ''newrecipient'' address is [[wp:personally identifiable information]] of its owner, therefore its owner should have explicitly given a permission to use it in a certain way. That permission, also called ''opt-in'', is not routinely asked for. Even when it is, e.g. when subscribing to a mailing list, the relevant forwarding recipe is stored at the forwarding host only. [[Forwarding agreement]]s are proposed to obviate this limitation and let a forwarding recipe be known and acted upon by its owner, directly from the target host.

=== Envelope sender tweak ===
An easy technique to let the sending software know that a message is being forwarded is by changing the envelope sender to some special value that is only understood within the host/ADMD. For example
 &amp;nbsp;&lt;code&gt;| sendmail -f ff=&lt;i&gt;keyword&lt;/i&gt;=&lt;i&gt;param&lt;/i&gt;=postmaster@example.org newrecipient@example.com&lt;/code&gt;
The line above provides a keyword and a parameter for using an existing forwarding agreement, or start negotiating one. The sending software, upon seeing that the remote MX accepts the ''ff'' model, shall search a local database for a record corresponding to &lt;code&gt;newrecipient@example.com&lt;/code&gt;, the remote MX, and the keyword parameter. That record is considered a ''complement'' of the forwarding recipe.

If the record is found and contains an id/password for logging in, the sending software recovers the original envelope sender from the ''Return-Path'' header and forwards the message according to this model. For ongoing negotiations, the record may contain an indication to either queue the message or send it normally until the negotiation completes. Otherwise, the keyword and parameter can be used to load a configurated environment and launch the first step of the negotiation. In this case the return code indicates whether to queue the message or sending it normally.

Sending the message normally, which is also done in case the remote MX does not support ''FF'', implies using the default envelope sender, in this case &lt;code&gt;postmaster@example.org&lt;/code&gt;. The tweaked envelope sender never leaves the relevant host. However, it may be set on an internal host inside the same ADMD in case the existing forwarding recipe is not on a boundary host.

== Policy considerations ==
In its simplest form, a forwarding recipe may be difficult to manage. The complexity may increase depending on who and how can create mailboxes and recipes on the system, what spam filtering options are available, and spam reporting mechanisms.

On a small system where only the postmaster creates mailboxes and recipes, for example, a recipe as exemplified above may make sense. Upon receiving a delivery failure, the postmaster should decide whether to drop the recipe as the target address becomes unavailable or to advise the final recipient that the relevant mailbox is full. Larger systems will require to automate that behavior, therefore it becomes necessary to define exactly when and how each operation is performed. For example, a policy can specify a different behavior for a mailbox full situation if an alternative email address or, say, an SMS-enabled phone number are available for advising the final recipient.

A policy may contain various configuration items. It can provide for a number of different states, so that the server can stop receiving new mail in certain cases, possibly requiring that appropriate local responses are given, e.g.:
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;, or 
251  User not local; will forward to &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

Two flags are as follows:
* '''enabled''': mail is accepted, and
* '''non-disclosure''': the target address shall never be revealed.

As a forwarding recipe's policy is limited to local behavior, the ''non-disclosure'' flag affects the text in the server response, and do DSNs and MDNs as for lists. See RFC 3461, ''5.2.7.4 confidential forwarding addresses''; RFC 3798, ''6.2. Privacy''; RFC 3885.</text>
    <sha1>ba67e5b94bc912679c4041b0e3c1c47904ec7dd7</sha1>
  </revision>
  <revision>
    <id>1551</id>
    <parentid>1550</parentid>
    <timestamp>2010-07-21T08:44:34Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Undo revision 1548 by [[Special:Contributions/Meryl20|Meryl20]] ([[User talk:Meryl20|Talk]])</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6504" xml:space="preserve">A '''forwarding recipe''' is the procedural data by which a mail server can build a new envelope for an existing message before re-injecting it into the mail system. It includes the forwarded address that the original message bore, one or more new recipient addresses to whom the re-injected message is destined, and a policy. The policy determines the new envelope sender address, at least.

== Common forwarding recipes ==
=== Static recipes ===
Historically, recipes were written in [http://www.sendmail.org/ sendmail]'s &lt;code&gt;.forward&lt;/code&gt; files in a recipient's home directory, in order to elicit specific forwarding behavior from the server when a message is received at a given mailbox. Recipes have to be addressable by their forwarded address, so that the software can find any relevant recipe upon message reception. Obviously, the software that implements the SMTP server dictates the format that recipes have to comply. Depending on the implementation, the data that conceptually makes up a recipe may be spread among several files.

A pipe character (&lt;code&gt;|&lt;/code&gt;) in a &lt;code&gt;.forward&lt;/code&gt; file allows executing external programs. Similar concepts work for [http://www.qmail.org/man/man5/dot-qmail.html .qmail] and [http://www.courier-mta.org/dot-courier.html .courier]. A forwarding recipe may consist of
 &amp;nbsp;&lt;code&gt;| sendmail -f postmaster@example.org newrecipient@example.com&lt;/code&gt;

Notice that the forwarded address is implied by the location on disc where the recipe is written. In addition, the behavior triggered by messages bouncing to &lt;code&gt;postmaster@example.org&lt;/code&gt; is conceptually part of this recipe but is specified somewhere else.

=== Newsletters and mailing lists ===
Dynamic recipes are managed by specialized software. Such software has well defined schemata to precisely define what messages are forwarded to what addresses. A number of ''best practices'' documents exists that specify how to reliably send bulk mail, e.g. [http://mipassoc.org/spamops/index.html MIPAssoc]. In case the model proposed here will be adopted, it may be added to the list of things to do, but it will have to be done on a per-package basis.

=== Backup MXes ===
&lt;!-- TODO: add template {{main|Forwarding agreement}} --&gt;
''Main article: [[Backup MX]]''

A backup MX also does forwarding. What is special in it, is that forwarding recipes are ''implicit''.

== Quest for agreement ==
A forwarding recipe introduces a new segment in the message path, which should be considered within the recipient's realm. In fact, the ''newrecipient'' address is [[wp:personally identifiable information]] of its owner, therefore its owner should have explicitly given a permission to use it in a certain way. That permission, also called ''opt-in'', is not routinely asked for. Even when it is, e.g. when subscribing to a mailing list, the relevant forwarding recipe is stored at the forwarding host only. [[Forwarding agreement]]s are proposed to obviate this limitation and let a forwarding recipe be known and acted upon by its owner, directly from the target host.

=== Envelope sender tweak ===
An easy technique to let the sending software know that a message is being forwarded is by changing the envelope sender to some special value that is only understood within the host/ADMD. For example
 &amp;nbsp;&lt;code&gt;| sendmail -f ff=&lt;i&gt;keyword&lt;/i&gt;=&lt;i&gt;param&lt;/i&gt;=postmaster@example.org newrecipient@example.com&lt;/code&gt;
The line above provides a keyword and a parameter for using an existing forwarding agreement, or start negotiating one. The sending software, upon seeing that the remote MX accepts the ''ff'' model, shall search a local database for a record corresponding to &lt;code&gt;newrecipient@example.com&lt;/code&gt;, the remote MX, and the keyword parameter. That record is considered a ''complement'' of the forwarding recipe.

If the record is found and contains an id/password for logging in, the sending software recovers the original envelope sender from the ''Return-Path'' header and forwards the message according to this model. For ongoing negotiations, the record may contain an indication to either queue the message or send it normally until the negotiation completes. Otherwise, the keyword and parameter can be used to load a configurated environment and launch the first step of the negotiation. In this case the return code indicates whether to queue the message or sending it normally.

Sending the message normally, which is also done in case the remote MX does not support ''FF'', implies using the default envelope sender, in this case &lt;code&gt;postmaster@example.org&lt;/code&gt;. The tweaked envelope sender never leaves the relevant host. However, it may be set on an internal host inside the same ADMD in case the existing forwarding recipe is not on a boundary host.

== Policy considerations ==
In its simplest form, a forwarding recipe may be difficult to manage. The complexity may increase depending on who and how can create mailboxes and recipes on the system, what spam filtering options are available, and spam reporting mechanisms.

On a small system where only the postmaster creates mailboxes and recipes, for example, a recipe as exemplified above may make sense. Upon receiving a delivery failure, the postmaster should decide whether to drop the recipe as the target address becomes unavailable or to advise the final recipient that the relevant mailbox is full. Larger systems will require to automate that behavior, therefore it becomes necessary to define exactly when and how each operation is performed. For example, a policy can specify a different behavior for a mailbox full situation if an alternative email address or, say, an SMS-enabled phone number are available for advising the final recipient.

A policy may contain various configuration items. It can provide for a number of different states, so that the server can stop receiving new mail in certain cases, possibly requiring that appropriate local responses are given, e.g.:
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;, or 
251  User not local; will forward to &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

Two flags are as follows:
* '''enabled''': mail is accepted, and
* '''non-disclosure''': the target address shall never be revealed.

As a forwarding recipe's policy is limited to local behavior, the ''non-disclosure'' flag affects the text in the server response, and do DSNs and MDNs as for lists. See RFC 3461, ''5.2.7.4 confidential forwarding addresses''; RFC 3798, ''6.2. Privacy''; RFC 3885.</text>
    <sha1>8b3eca6d84f698bc37acdbdea8501a6e45c73645</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>boundary</title>
  <ns>0</ns>
  <id>14</id>
  <revision>
    <id>1527</id>
    <parentid>1449</parentid>
    <timestamp>2009-05-23T09:29:53Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Backup MXes */ add link to ''Backup MX''</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2801" xml:space="preserve">In a given message path, there is a well determined '''boundary''' between the mail originating network (MON) and the mail receiving network (MRN). It lies where the first MX is looked up in the global DNS in order to determine the receiver for the next hop.

== Topology ==
The boundary is defined by the MX records of the recipient's domain in the ''global'' DNS. Internal DNS views may provide for outgoing mail paths, as an alternative to MTA-specific configuration. Because DNS is global, the domain servers are uniquely identified.

The same message may follow different paths at different times, depending on connection availability, DNS changes, and DNS randomization. In addition, when the recipient changes, the path changes widely. It can well happen that the same host is on one side of the boundary for message A, and it happens to be on the other side for message B, even if both messages end up to the same target host. On the other hand, the whole path may consist of a single server, resulting in a degenerated boundary inside it.

This topology is not necessarily related to ADministrative Management Domains (ADMDs). On the one hand, hosts belonging to an ADMD may end up not being involved in any inter-domain forwarding. On the other hand, hosts that don't belong to an ADMD may negotiate an agreement and enjoy the amount of trust that is required to perform inter-domain forwarding.

== Forwarders ==
Relays performing alias expansion are considered part of the MRN, if they use the target address legitimately.

== Backup MXes ==
&lt;!-- TODO: add template {{main|Forwarding agreement}} --&gt;
''Main article: [[Backup MX]]''

A message may pass through a backup MX if a direct connection to the target server is not available. The backup MX is considered part of the MRN, even if it currently does not have a list of valid users.

The way backup MXes currently operate generates backscatter. This, and the fact that connections are often very reliable, results in diminished use of backup MXes. Only large networks operate them, and they are usually in the same ADMD.

It is possible that the [[solution proposed]] here results in enhanced backup MXes operations. A backup MX has an implicit list of valid mailboxes that comprises any possible address within the given domain(s). However, it still needs to gather forwarding agreements explicitly. That would result in having an almost complete list of users. It may reply with a 4xx code for new users that are not in the agreements database. Additional mechanisms are needed (e.g. temporary blacklists of addresses, maximum allowed queries per time period) to make that behavior smooth.

== See Also ==
*[http://www.openspf.org/Community/Glossary SPF Community Glossary] has some more terminology and mentions where it originated.</text>
    <sha1>1d63a0fdc3a2d7b240a4f45dda337f89a5c889b3</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>Backup MX</title>
  <ns>0</ns>
  <id>26</id>
  <revision>
    <id>1528</id>
    <timestamp>2009-05-23T10:46:14Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>start new page</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="3365" xml:space="preserve">A '''backup MX''', also called a '''secondary MX''', is an optional server that accepts mail for the target domain on behalf of the ''primary MX''. It does not store messages in users' mailboxes, but will attempt to relay them to a primary server.

== Why have a backup MX ==
There are two main reasons why a primary MX may not be reachable: Server or network outages. Server outages are not much of a problem, except for outgoing servers that are configured with an unacceptably low retry interval. Some postmaster do so because they think that delayed DSNs can be difficult to understand for their users. That way, they won't be able to cope with a target host being temporarily down for a few days. According to RFC 5321, ''the give-up time generally needs to be at least 4-5 days.''

Network outages are more subtle. There was an era when backup MXes were useful to deal with networks that didn't have routes to some parts of the net. That's a pretty small niche now. However, asymmetric routing faults are still pretty common, especially in developing countries. A conservative setup may provide for a backup MX somewhere else that has a backup link to get mail to the primary when regular connectivity isn't working. An additional concern is that backbone links may go down due to [http://science.nasa.gov/headlines/y2006/10mar_stormwarning.htm solar activity], terrorism, or war. A backup MX in Australia, for example, may make a message be timely delivered from the US to Europe even if the Atlantic link is down.

== Why not to have a backup MX ==
With multiple connections and good hardware, it is not difficult to have 99+% uptime. Considering that performance an indicator of future results, backup MXes can be ruled out. However, the real reason for doing so is [[wp:Backscatter (e-mail)|backscatter]].

According to current standards and best practices, in order to setup a backup MX for ''example.com'', it is enough to
# configure the backup server, e.g. ''backup.example.org'', to accept mail for ''example.com'', and
# add a record in ''example.com'' DNS zone, saying that ''backup.example.org'' is an MX server with less preference (higher number) than the primary.

In principle, a client should attempt to deliver mail at the target domain's ''preferred'' (primary) server. However, spammers are exempted, and it is not easy for a secondary server to establish whether a client could have reached the primary at a given time (if the secondary can reach the primary, the primary may attempt to trace its route to the client and communicate the result back to the secondary.) A backup MX should accept mail destined to ''any'' user of the domain backed up (''example.com''), unless it has a copy of the users' database.

Currently, organizations that coordinate several servers across various networks, may internally arrange for a cache of the users database to be available at a backup MX's. Organizations whose networks would require to outsource them, while primary MXes are contracted in, cannot do that. Thay are better off avoiding a backup MX, because mail accepted by the backup for nonexistent users would result in backscatter. Thus, they may be in for a hard surprise in case connections worsen.

&lt;!-- == Alternatives and requirements ==

A cute trick 
--&gt;
== See also ==
* [[boundary#Backup MXes]]
* [[forwarding recipe#Backup MXes]]</text>
    <sha1>9971dd64a9b89c333e272dfd8dab1ebeb1e10f19</sha1>
  </revision>
  <revision>
    <id>1529</id>
    <parentid>1528</parentid>
    <timestamp>2009-05-23T12:04:20Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Continue page</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5862" xml:space="preserve">A '''backup MX''', also called a '''secondary MX''', is an optional server that accepts mail for the target domain on behalf of the ''primary MX''. It does not store messages in users' mailboxes, but will attempt to relay them to a primary server.

== Why have a backup MX ==
There are two main reasons why a primary MX may not be reachable: Server or network outages. Server outages are not much of a problem, except for outgoing servers that are configured with an unacceptably low retry interval. Some postmaster do so because they think that delayed DSNs can be difficult to understand for their users. That way, they won't be able to cope with a target host being temporarily down for a few days. According to RFC 5321, ''the give-up time generally needs to be at least 4-5 days.''

Network outages are more subtle. There was an era when backup MXes were useful to deal with networks that didn't have routes to some parts of the net. That's a pretty small niche now. However, asymmetric routing faults are still pretty common, especially in developing countries. A conservative setup may provide for a backup MX somewhere else that has a backup link to get mail to the primary when regular connectivity isn't working. An additional concern is that backbone links may go down due to [http://science.nasa.gov/headlines/y2006/10mar_stormwarning.htm solar activity], terrorism, or war. A backup MX in Australia, for example, may make a message be timely delivered from the US to Europe even if the Atlantic link is down.

== Why not to have a backup MX ==
With multiple connections and good hardware, it is not difficult to have 99+% uptime. Considering that performance an indicator of future results, backup MXes can be ruled out. However, the real reason for doing so is [[wp:Backscatter (e-mail)|backscatter]].

According to current standards and best practices, in order to setup a backup MX for ''example.com'', it is enough to
# configure the backup server, e.g. ''backup.example.org'', to accept mail for ''example.com'', and
# add a record in ''example.com'' DNS zone, saying that ''backup.example.org'' is an MX server with less preference (higher number) than the primary.

In principle, a client should attempt to deliver mail at the target domain's ''preferred'' (primary) server. However, spammers are exempted, and it is not easy for a secondary server to establish whether a client could have reached the primary at a given time (if the secondary can reach the primary, the primary may attempt to trace its route to the client and communicate the result back to the secondary.) A backup MX should accept mail destined to ''any'' user of the domain backed up (''example.com''), unless it has a copy of the users' database.

Currently, organizations that coordinate several servers across various networks, may internally arrange for a cache of the users database to be available at a backup MX's. Organizations whose networks would require to outsource them, while primary MXes are contracted in, cannot do that. They are better off avoiding a backup MX, because mail accepted by the backup for nonexistent users would result in backscatter. Thus, they may be in for a hard surprise in case connections worsen.

== Alternatives and requirements ==

The [[solution proposed]] for forwarding may somewhat lend itself for also doing backup MXes. That scenario implies that a backup MX has implicit [[forwarding recipe]]s for all users to all more preferred servers in the domain being backed up. The backup server would still have to negotiate a [[forwarding agreement]] in each case where a message actually has to go through for the first time. (Existing recipes are to be searched before implicit ones.)

A cute trick to initialize the system so that it doesn't have to reply 4xx codes until agreements are finalized, which is likely to happen if the primary host is down, is to provide a list of hashed email addresses. That way, a backup MX may check that a given address actually exists, and accept it, being confident that the primary server will accept it in turn. The forwarding agreement will be negotiated when the primary (or a more preferred secondary) comes up. That circumstance more or less coincides with the moment when the cleartext address corresponding to the hashed entry becomes known at the server. Since provisions for accepting forwarding agreements from a backup MX should have been set up already at the primary's, we can regard as substantially irrelevant the short period of time while the first message for a given address remains stored in the backup MX's cache. (During that time, the server knows the email address without being bound by an agreement.)

Besides the list of hashes, the ''initialization data'', may contain regular expressions to account for subaddresses, prefixes, catch-all's, honeypots, etcetera. More meta data may be needed. Provisions to periodically refresh the initialization data are also needed. Changes in the DNS that add or remove MXes, or just change preferences, have to be dealt with.

End users should not be able to delete their forwarding agreement at a backup MX, unless they also delete their mailbox at the primary MX. Blocking such agreements, i.e. leaving an existing recipe in place while configuring it to reply ''551 User not local'', may result in some disruption and noncompliance. Such blocking may be disallowed by domain policies. At any rate, privacy concerned users will gain the ability to retrieve the effective list of servers where their email addresses are stored (a somewhat idealistic wish, until some marketing function will say otherwise.)

== See also ==
* [[boundary#Backup MXes]]
* [[forwarding recipe#Backup MXes]]
* The [http://www.imc.org/ietf-smtp/mail-archive/msg05696.html ietf-smtp thread] that inspired this page
* [[wp:MX record#The backup MX]]</text>
    <sha1>3b1ff52b6736ecfbfcec56f2d6898b0142a47df7</sha1>
  </revision>
  <revision>
    <id>1530</id>
    <parentid>1529</parentid>
    <timestamp>2009-05-23T13:42:08Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Why have a backup MX */ typo</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5866" xml:space="preserve">A '''backup MX''', also called a '''secondary MX''', is an optional server that accepts mail for the target domain on behalf of the ''primary MX''. It does not store messages in users' mailboxes, but will attempt to relay them to a primary server.

== Why have a backup MX ==
There are two main reasons why a primary MX may not be reachable: Server or network outages. Server outages are not much of a problem, except for outgoing servers that are configured with an unacceptably low retry interval. Some postmasters do so because they think that delayed DSNs are difficult to understand for their users. That way, they won't be able to cope with a target host being temporarily down for a few days. According to RFC 5321, ''the give-up time generally needs to be at least 4-5 days.''

Network outages are more subtle. There was an era when backup MXes were useful to deal with networks that didn't have routes to some parts of the net. That's a pretty small niche now. However, asymmetric routing faults are still pretty common, especially in developing countries. A conservative setup may provide for a backup MX somewhere else that has a backup link to get mail to the primary when regular connectivity isn't working. An additional concern is that backbone links may go down due to [http://science.nasa.gov/headlines/y2006/10mar_stormwarning.htm solar activity], terrorism, or war. A backup MX in Australia, for example, may make a message to be timely delivered from the US to Europe even while the Atlantic link is down.

== Why not to have a backup MX ==
With multiple connections and good hardware, it is not difficult to have 99+% uptime. Considering that performance an indicator of future results, backup MXes can be ruled out. However, the real reason for doing so is [[wp:Backscatter (e-mail)|backscatter]].

According to current standards and best practices, in order to setup a backup MX for ''example.com'', it is enough to
# configure the backup server, e.g. ''backup.example.org'', to accept mail for ''example.com'', and
# add a record in ''example.com'' DNS zone, saying that ''backup.example.org'' is an MX server with less preference (higher number) than the primary.

In principle, a client should attempt to deliver mail at the target domain's ''preferred'' (primary) server. However, spammers are exempted, and it is not easy for a secondary server to establish whether a client could have reached the primary at a given time (if the secondary can reach the primary, the primary may attempt to trace its route to the client and communicate the result back to the secondary.) A backup MX should accept mail destined to ''any'' user of the domain backed up (''example.com''), unless it has a copy of the users' database.

Currently, organizations that coordinate several servers across various networks, may internally arrange for a cache of the users database to be available at a backup MX's. Organizations whose networks would require to outsource them, while primary MXes are contracted in, cannot do that. They are better off avoiding a backup MX, because mail accepted by the backup for nonexistent users would result in backscatter. Thus, they may be in for a hard surprise in case connections worsen.

== Alternatives and requirements ==

The [[solution proposed]] for forwarding may somewhat lend itself for also doing backup MXes. That scenario implies that a backup MX has implicit [[forwarding recipe]]s for all users to all more preferred servers in the domain being backed up. The backup server would still have to negotiate a [[forwarding agreement]] in each case where a message actually has to go through for the first time. (Existing recipes are to be searched before implicit ones.)

A cute trick to initialize the system so that it doesn't have to reply 4xx codes until agreements are finalized, which is likely to happen if the primary host is down, is to provide a list of hashed email addresses. That way, a backup MX may check that a given address actually exists, and accept it, being confident that the primary server will accept it in turn. The forwarding agreement will be negotiated when the primary (or a more preferred secondary) comes up. That circumstance more or less coincides with the moment when the cleartext address corresponding to the hashed entry becomes known at the server. Since provisions for accepting forwarding agreements from a backup MX should have been set up already at the primary's, we can regard as substantially irrelevant the short period of time while the first message for a given address remains stored in the backup MX's cache. (During that time, the server knows the email address without being bound by an agreement.)

Besides the list of hashes, the ''initialization data'', may contain regular expressions to account for subaddresses, prefixes, catch-all's, honeypots, etcetera. More meta data may be needed. Provisions to periodically refresh the initialization data are also needed. Changes in the DNS that add or remove MXes, or just change preferences, have to be dealt with.

End users should not be able to delete their forwarding agreement at a backup MX, unless they also delete their mailbox at the primary MX. Blocking such agreements, i.e. leaving an existing recipe in place while configuring it to reply ''551 User not local'', may result in some disruption and noncompliance. Such blocking may be disallowed by domain policies. At any rate, privacy concerned users will gain the ability to retrieve the effective list of servers where their email addresses are stored (a somewhat idealistic wish, until some marketing function will say otherwise.)

== See also ==
* [[boundary#Backup MXes]]
* [[forwarding recipe#Backup MXes]]
* The [http://www.imc.org/ietf-smtp/mail-archive/msg05696.html ietf-smtp thread] that inspired this page
* [[wp:MX record#The backup MX]]</text>
    <sha1>a27811e673def845ae4c07fe82348e4ff2c5f0f1</sha1>
  </revision>
  <revision>
    <id>1531</id>
    <parentid>1530</parentid>
    <timestamp>2009-05-25T08:51:38Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Why have a backup MX */ add John Klensin's notes</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6533" xml:space="preserve">A '''backup MX''', also called a '''secondary MX''', is an optional server that accepts mail for the target domain on behalf of the ''primary MX''. It does not store messages in users' mailboxes, but will attempt to relay them to a primary server.

== Why have a backup MX ==
There are two main reasons why a primary MX may not be reachable: Server or network outages. Server outages are not much of a problem, except for outgoing servers that are configured with an unacceptably low retry interval. Some postmasters do so because they think that delayed DSNs are difficult to understand for their users. That way, they won't be able to cope with a target host being temporarily down for a few days. According to RFC 5321, ''the give-up time generally needs to be at least 4-5 days.''

Network outages are more subtle. There was an era when backup MXes were useful to deal with networks that didn't have routes to some parts of the net. That's a pretty small niche now. However, asymmetric routing faults are still pretty common, especially in developing countries. A conservative setup may provide for a backup MX somewhere else that has a backup link to get mail to the primary when regular connectivity isn't working. An additional concern is that backbone links may go down due to [http://science.nasa.gov/headlines/y2006/10mar_stormwarning.htm solar activity], terrorism, or war. A backup MX in Australia, for example, may make a message to be timely delivered from the US to Europe even while the Atlantic link is down.

A third reason for setting up a "backup MX" is to explicitly acquire connectivity even when no outage disrupts normal operations. For example, the target host is on Mars and can be accessed, easily and normally, by other Martian hosts.  However,
	for a host on Earth, the target host will rarely be
	reachable via a normal TCP/SMTP connection and the
	intermediate MX host may have the needed delay-tolerant
	machinery installed.

In any case, SMTP provides for a default for transferring mail from the backup MX to the target host. That is not a requirement, though. LMTP (RFC 2033), UUCP (RFC 976), or any any other mutually-acceptable transport mechanism may do.

== Why not to have a backup MX ==
With multiple connections and good hardware, it is not difficult to have 99+% uptime. Considering that performance an indicator of future results, backup MXes can be ruled out. However, the real reason for doing so is [[wp:Backscatter (e-mail)|backscatter]].

According to current standards and best practices, in order to setup a backup MX for ''example.com'', it is enough to
# configure the backup server, e.g. ''backup.example.org'', to accept mail for ''example.com'', and
# add a record in ''example.com'' DNS zone, saying that ''backup.example.org'' is an MX server with less preference (higher number) than the primary.

In principle, a client should attempt to deliver mail at the target domain's ''preferred'' (primary) server. However, spammers are exempted, and it is not easy for a secondary server to establish whether a client could have reached the primary at a given time (if the secondary can reach the primary, the primary may attempt to trace its route to the client and communicate the result back to the secondary.) A backup MX should accept mail destined to ''any'' user of the domain backed up (''example.com''), unless it has a copy of the users' database.

Currently, organizations that coordinate several servers across various networks, may internally arrange for a cache of the users database to be available at a backup MX's. Organizations whose networks would require to outsource them, while primary MXes are contracted in, cannot do that. They are better off avoiding a backup MX, because mail accepted by the backup for nonexistent users would result in backscatter. Thus, they may be in for a hard surprise in case connections worsen.

== Alternatives and requirements ==

The [[solution proposed]] for forwarding may somewhat lend itself for also doing backup MXes. That scenario implies that a backup MX has implicit [[forwarding recipe]]s for all users to all more preferred servers in the domain being backed up. The backup server would still have to negotiate a [[forwarding agreement]] in each case where a message actually has to go through for the first time. (Existing recipes are to be searched before implicit ones.)

A cute trick to initialize the system so that it doesn't have to reply 4xx codes until agreements are finalized, which is likely to happen if the primary host is down, is to provide a list of hashed email addresses. That way, a backup MX may check that a given address actually exists, and accept it, being confident that the primary server will accept it in turn. The forwarding agreement will be negotiated when the primary (or a more preferred secondary) comes up. That circumstance more or less coincides with the moment when the cleartext address corresponding to the hashed entry becomes known at the server. Since provisions for accepting forwarding agreements from a backup MX should have been set up already at the primary's, we can regard as substantially irrelevant the short period of time while the first message for a given address remains stored in the backup MX's cache. (During that time, the server knows the email address without being bound by an agreement.)

Besides the list of hashes, the ''initialization data'', may contain regular expressions to account for subaddresses, prefixes, catch-all's, honeypots, etcetera. More meta data may be needed. Provisions to periodically refresh the initialization data are also needed. Changes in the DNS that add or remove MXes, or just change preferences, have to be dealt with.

End users should not be able to delete their forwarding agreement at a backup MX, unless they also delete their mailbox at the primary MX. Blocking such agreements, i.e. leaving an existing recipe in place while configuring it to reply ''551 User not local'', may result in some disruption and noncompliance. Such blocking may be disallowed by domain policies. At any rate, privacy concerned users will gain the ability to retrieve the effective list of servers where their email addresses are stored (a somewhat idealistic wish, until some marketing function will say otherwise.)

== See also ==
* [[boundary#Backup MXes]]
* [[forwarding recipe#Backup MXes]]
* The [http://www.imc.org/ietf-smtp/mail-archive/msg05696.html ietf-smtp thread] that inspired this page
* [[wp:MX record#The backup MX]]</text>
    <sha1>bb89926858dfcc7baf0c25289fc8dcc22040ebac</sha1>
  </revision>
  <revision>
    <id>1556</id>
    <parentid>1531</parentid>
    <timestamp>2010-09-24T08:33:48Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Why have a backup MX */ expand slightly</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7289" xml:space="preserve">A '''backup MX''', also called a '''secondary MX''', is an optional server that accepts mail for the target domain on behalf of the ''primary MX''. It does not store messages in users' mailboxes, but will attempt to relay them to a primary server.

== Why have a backup MX ==
There are two main reasons why a primary MX may not be reachable: Server or network outages.

Server outages are a problem also for retrieving mail, via IMAP or POP. It may make sense to run a backup MX in case backup hosts are available for retrieving mail, in a fault-tolerant infrastructure. Minor annoyance may result from non-compliant transmitters that are configured with an unacceptably low retry interval. According to RFC 5321, ''the give-up time generally needs to be at least 4-5 days.'' A few postmasters configure much shorter intervals, perhaps because they think that delayed DSNs are difficult to understand for their users. That way, they won't be able to cope with a target host being temporarily down for a few days.

Network outages are more subtle. There was an era when backup MXes were useful to deal with networks that didn't have routes to some parts of the net. That's a pretty small niche now. However, asymmetric routing faults are still pretty common, especially in developing countries. A conservative setup may provide for a backup MX somewhere else that has a backup link to get mail to the primary when regular connectivity isn't working. An additional concern is that backbone links may go down due to [http://science.nasa.gov/headlines/y2006/10mar_stormwarning.htm solar activity], terrorism, or war. A backup MX in Australia, for example, may make a message to be timely delivered from the US to Europe even while the Atlantic link is down.

A third reason for setting up a "backup MX" is to explicitly acquire connectivity even when no outage disrupts normal operations. For example, the target host is on Mars and can be accessed, easily and normally, by other Martian hosts.  However,
	for a host on Earth, the target host will rarely be
	reachable via a normal TCP/SMTP connection and the
	intermediate MX host may have the needed delay-tolerant
	machinery installed&lt;ref&gt;John Klensin, [http://www.imc.org/ietf-smtp/mail-archive/msg05713.html ietf-smtp.imc.org], Sat, 23 May 2009 11:10:48 -0400&lt;/ref&gt;
On the Earth, a more common example is provided by (large) enterprises who  operate dedicated boundary servers as their MX platforms, and handle final delivery by an entirely different set of servers often totally invisible to the outside user.&lt;ref&gt;Malcolm Weir, [http://www.mail-archive.com/courier-users@lists.sourceforge.net/msg35222.html courier-users], Wed, 22 Sep 2010 16:00:19 -0700&lt;/ref&gt;

In any case, SMTP provides for a default for transferring mail from the backup MX to the target host. That is not a requirement, though. LMTP (RFC 2033), UUCP (RFC 976), or any any other mutually-acceptable transport mechanism may do.

== Why not to have a backup MX ==
With multiple connections and good hardware, it is not difficult to have 99+% uptime. Considering that performance an indicator of future results, backup MXes can be ruled out. However, the real reason for doing so is [[wp:Backscatter (e-mail)|backscatter]].

According to current standards and best practices, in order to setup a backup MX for ''example.com'', it is enough to
# configure the backup server, e.g. ''backup.example.org'', to accept mail for ''example.com'', and
# add a record in ''example.com'' DNS zone, saying that ''backup.example.org'' is an MX server with less preference (higher number) than the primary.

In principle, a client should attempt to deliver mail at the target domain's ''preferred'' (primary) server. However, spammers are exempted, and it is not easy for a secondary server to establish whether a client could have reached the primary at a given time (if the secondary can reach the primary, the primary may attempt to trace its route to the client and communicate the result back to the secondary.) A backup MX should accept mail destined to ''any'' user of the domain backed up (''example.com''), unless it has a copy of the users' database.

Currently, organizations that coordinate several servers across various networks, may internally arrange for a cache of the users database to be available at a backup MX's. Organizations whose networks would require to outsource them, while primary MXes are contracted in, cannot do that. They are better off avoiding a backup MX, because mail accepted by the backup for nonexistent users would result in backscatter. Thus, they may be in for a hard surprise in case connections worsen.

== Alternatives and requirements ==

The [[solution proposed]] for forwarding may somewhat lend itself for also doing backup MXes. That scenario implies that a backup MX has implicit [[forwarding recipe]]s for all users to all more preferred servers in the domain being backed up. The backup server would still have to negotiate a [[forwarding agreement]] in each case where a message actually has to go through for the first time. (Existing recipes are to be searched before implicit ones.)

A cute trick to initialize the system so that it doesn't have to reply 4xx codes until agreements are finalized, which is likely to happen if the primary host is down, is to provide a list of hashed email addresses. That way, a backup MX may check that a given address actually exists, and accept it, being confident that the primary server will accept it in turn. The forwarding agreement will be negotiated when the primary (or a more preferred secondary) comes up. That circumstance more or less coincides with the moment when the cleartext address corresponding to the hashed entry becomes known at the server. Since provisions for accepting forwarding agreements from a backup MX should have been set up already at the primary's, we can regard as substantially irrelevant the short period of time while the first message for a given address remains stored in the backup MX's cache. (During that time, the server knows the email address without being bound by an agreement.)

Besides the list of hashes, the ''initialization data'', may contain regular expressions to account for subaddresses, prefixes, catch-all's, honeypots, etcetera. More meta data may be needed. Provisions to periodically refresh the initialization data are also needed. Changes in the DNS that add or remove MXes, or just change preferences, have to be dealt with.

End users should not be able to delete their forwarding agreement at a backup MX, unless they also delete their mailbox at the primary MX. Blocking such agreements, i.e. leaving an existing recipe in place while configuring it to reply ''551 User not local'', may result in some disruption and noncompliance. Such blocking may be disallowed by domain policies. At any rate, privacy concerned users will gain the ability to retrieve the effective list of servers where their email addresses are stored (a somewhat idealistic wish, until some marketing function will say otherwise.)

== See also ==
* [[boundary#Backup MXes]]
* [[forwarding recipe#Backup MXes]]
* The [http://www.imc.org/ietf-smtp/mail-archive/msg05696.html ietf-smtp thread] that inspired this page
* [[wp:MX record#The backup MX]]</text>
    <sha1>ca6b5c2820315074d4cadd068a2bb2cab4214c5a</sha1>
  </revision>
  <revision>
    <id>1557</id>
    <parentid>1556</parentid>
    <timestamp>2010-09-24T08:34:34Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* See also */ add references</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7321" xml:space="preserve">A '''backup MX''', also called a '''secondary MX''', is an optional server that accepts mail for the target domain on behalf of the ''primary MX''. It does not store messages in users' mailboxes, but will attempt to relay them to a primary server.

== Why have a backup MX ==
There are two main reasons why a primary MX may not be reachable: Server or network outages.

Server outages are a problem also for retrieving mail, via IMAP or POP. It may make sense to run a backup MX in case backup hosts are available for retrieving mail, in a fault-tolerant infrastructure. Minor annoyance may result from non-compliant transmitters that are configured with an unacceptably low retry interval. According to RFC 5321, ''the give-up time generally needs to be at least 4-5 days.'' A few postmasters configure much shorter intervals, perhaps because they think that delayed DSNs are difficult to understand for their users. That way, they won't be able to cope with a target host being temporarily down for a few days.

Network outages are more subtle. There was an era when backup MXes were useful to deal with networks that didn't have routes to some parts of the net. That's a pretty small niche now. However, asymmetric routing faults are still pretty common, especially in developing countries. A conservative setup may provide for a backup MX somewhere else that has a backup link to get mail to the primary when regular connectivity isn't working. An additional concern is that backbone links may go down due to [http://science.nasa.gov/headlines/y2006/10mar_stormwarning.htm solar activity], terrorism, or war. A backup MX in Australia, for example, may make a message to be timely delivered from the US to Europe even while the Atlantic link is down.

A third reason for setting up a "backup MX" is to explicitly acquire connectivity even when no outage disrupts normal operations. For example, the target host is on Mars and can be accessed, easily and normally, by other Martian hosts.  However,
	for a host on Earth, the target host will rarely be
	reachable via a normal TCP/SMTP connection and the
	intermediate MX host may have the needed delay-tolerant
	machinery installed&lt;ref&gt;John Klensin, [http://www.imc.org/ietf-smtp/mail-archive/msg05713.html ietf-smtp.imc.org], Sat, 23 May 2009 11:10:48 -0400&lt;/ref&gt;
On the Earth, a more common example is provided by (large) enterprises who  operate dedicated boundary servers as their MX platforms, and handle final delivery by an entirely different set of servers often totally invisible to the outside user.&lt;ref&gt;Malcolm Weir, [http://www.mail-archive.com/courier-users@lists.sourceforge.net/msg35222.html courier-users], Wed, 22 Sep 2010 16:00:19 -0700&lt;/ref&gt;

In any case, SMTP provides for a default for transferring mail from the backup MX to the target host. That is not a requirement, though. LMTP (RFC 2033), UUCP (RFC 976), or any any other mutually-acceptable transport mechanism may do.

== Why not to have a backup MX ==
With multiple connections and good hardware, it is not difficult to have 99+% uptime. Considering that performance an indicator of future results, backup MXes can be ruled out. However, the real reason for doing so is [[wp:Backscatter (e-mail)|backscatter]].

According to current standards and best practices, in order to setup a backup MX for ''example.com'', it is enough to
# configure the backup server, e.g. ''backup.example.org'', to accept mail for ''example.com'', and
# add a record in ''example.com'' DNS zone, saying that ''backup.example.org'' is an MX server with less preference (higher number) than the primary.

In principle, a client should attempt to deliver mail at the target domain's ''preferred'' (primary) server. However, spammers are exempted, and it is not easy for a secondary server to establish whether a client could have reached the primary at a given time (if the secondary can reach the primary, the primary may attempt to trace its route to the client and communicate the result back to the secondary.) A backup MX should accept mail destined to ''any'' user of the domain backed up (''example.com''), unless it has a copy of the users' database.

Currently, organizations that coordinate several servers across various networks, may internally arrange for a cache of the users database to be available at a backup MX's. Organizations whose networks would require to outsource them, while primary MXes are contracted in, cannot do that. They are better off avoiding a backup MX, because mail accepted by the backup for nonexistent users would result in backscatter. Thus, they may be in for a hard surprise in case connections worsen.

== Alternatives and requirements ==

The [[solution proposed]] for forwarding may somewhat lend itself for also doing backup MXes. That scenario implies that a backup MX has implicit [[forwarding recipe]]s for all users to all more preferred servers in the domain being backed up. The backup server would still have to negotiate a [[forwarding agreement]] in each case where a message actually has to go through for the first time. (Existing recipes are to be searched before implicit ones.)

A cute trick to initialize the system so that it doesn't have to reply 4xx codes until agreements are finalized, which is likely to happen if the primary host is down, is to provide a list of hashed email addresses. That way, a backup MX may check that a given address actually exists, and accept it, being confident that the primary server will accept it in turn. The forwarding agreement will be negotiated when the primary (or a more preferred secondary) comes up. That circumstance more or less coincides with the moment when the cleartext address corresponding to the hashed entry becomes known at the server. Since provisions for accepting forwarding agreements from a backup MX should have been set up already at the primary's, we can regard as substantially irrelevant the short period of time while the first message for a given address remains stored in the backup MX's cache. (During that time, the server knows the email address without being bound by an agreement.)

Besides the list of hashes, the ''initialization data'', may contain regular expressions to account for subaddresses, prefixes, catch-all's, honeypots, etcetera. More meta data may be needed. Provisions to periodically refresh the initialization data are also needed. Changes in the DNS that add or remove MXes, or just change preferences, have to be dealt with.

End users should not be able to delete their forwarding agreement at a backup MX, unless they also delete their mailbox at the primary MX. Blocking such agreements, i.e. leaving an existing recipe in place while configuring it to reply ''551 User not local'', may result in some disruption and noncompliance. Such blocking may be disallowed by domain policies. At any rate, privacy concerned users will gain the ability to retrieve the effective list of servers where their email addresses are stored (a somewhat idealistic wish, until some marketing function will say otherwise.)

== See also ==
* [[boundary#Backup MXes]]
* [[forwarding recipe#Backup MXes]]
* The [http://www.imc.org/ietf-smtp/mail-archive/msg05696.html ietf-smtp thread] that inspired this page
* [[wp:MX record#The backup MX]]

== References ==
&lt;references/&gt;</text>
    <sha1>b3e0b50780cbc21f7bbdcf3c4cb53b2bc4f3c076</sha1>
  </revision>
  <revision>
    <id>1558</id>
    <parentid>1557</parentid>
    <timestamp>2010-09-24T09:27:53Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Why not to have a backup MX */ mention solar flares</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7505" xml:space="preserve">A '''backup MX''', also called a '''secondary MX''', is an optional server that accepts mail for the target domain on behalf of the ''primary MX''. It does not store messages in users' mailboxes, but will attempt to relay them to a primary server.

== Why have a backup MX ==
There are two main reasons why a primary MX may not be reachable: Server or network outages.

Server outages are a problem also for retrieving mail, via IMAP or POP. It may make sense to run a backup MX in case backup hosts are available for retrieving mail, in a fault-tolerant infrastructure. Minor annoyance may result from non-compliant transmitters that are configured with an unacceptably low retry interval. According to RFC 5321, ''the give-up time generally needs to be at least 4-5 days.'' A few postmasters configure much shorter intervals, perhaps because they think that delayed DSNs are difficult to understand for their users. That way, they won't be able to cope with a target host being temporarily down for a few days.

Network outages are more subtle. There was an era when backup MXes were useful to deal with networks that didn't have routes to some parts of the net. That's a pretty small niche now. However, asymmetric routing faults are still pretty common, especially in developing countries. A conservative setup may provide for a backup MX somewhere else that has a backup link to get mail to the primary when regular connectivity isn't working. An additional concern is that backbone links may go down due to [http://science.nasa.gov/headlines/y2006/10mar_stormwarning.htm solar activity], terrorism, or war. A backup MX in Australia, for example, may make a message to be timely delivered from the US to Europe even while the Atlantic link is down.

A third reason for setting up a "backup MX" is to explicitly acquire connectivity even when no outage disrupts normal operations. For example, the target host is on Mars and can be accessed, easily and normally, by other Martian hosts.  However,
	for a host on Earth, the target host will rarely be
	reachable via a normal TCP/SMTP connection and the
	intermediate MX host may have the needed delay-tolerant
	machinery installed&lt;ref&gt;John Klensin, [http://www.imc.org/ietf-smtp/mail-archive/msg05713.html ietf-smtp.imc.org], Sat, 23 May 2009 11:10:48 -0400&lt;/ref&gt;
On the Earth, a more common example is provided by (large) enterprises who  operate dedicated boundary servers as their MX platforms, and handle final delivery by an entirely different set of servers often totally invisible to the outside user.&lt;ref&gt;Malcolm Weir, [http://www.mail-archive.com/courier-users@lists.sourceforge.net/msg35222.html courier-users], Wed, 22 Sep 2010 16:00:19 -0700&lt;/ref&gt;

In any case, SMTP provides for a default for transferring mail from the backup MX to the target host. That is not a requirement, though. LMTP (RFC 2033), UUCP (RFC 976), or any any other mutually-acceptable transport mechanism may do.

== Why not to have a backup MX ==
With multiple connections and good hardware, it is not difficult to have 99+% uptime. Considering that performance an indicator of future results, backup MXes can be ruled out. However, the real reason for doing so is [[wp:Backscatter (e-mail)|backscatter]].

According to current standards and best practices, in order to setup a backup MX for ''example.com'', it is enough to
# configure the backup server, e.g. ''backup.example.org'', to accept mail for ''example.com'', and
# add a record in ''example.com'' DNS zone, saying that ''backup.example.org'' is an MX server with less preference (higher number) than the primary.

In principle, a client should attempt to deliver mail at the target domain's ''preferred'' (primary) server. However, spammers are exempted, and it is not easy for a secondary server to establish whether a client could have reached the primary at a given time (if the secondary can reach the primary, the primary may attempt to trace its route to the client and communicate the result back to the secondary.) A backup MX should accept mail destined to ''any'' user of the domain backed up (''example.com''), unless it has a copy of the users' database.

Currently, organizations that coordinate several servers across various networks, may internally arrange for a cache of the users database to be available at a backup MX's. Organizations whose networks would require to outsource them, while primary MXes are contracted in, cannot do that. They are better off avoiding a backup MX, because mail accepted by the backup for nonexistent users would result in backscatter. Thus, they may be in for a hard surprise in case connections worsen, e.g. because of solar flares&lt;ref&gt;[http://www.nasa.gov/topics/solarsystem/features/spaceweather_hazard.html NASA-Funded Study Reveals Hazards of Severe Space Weather] 1 May 2009&lt;/ref&gt;.

== Alternatives and requirements ==

The [[solution proposed]] for forwarding may somewhat lend itself for also doing backup MXes. That scenario implies that a backup MX has implicit [[forwarding recipe]]s for all users to all more preferred servers in the domain being backed up. The backup server would still have to negotiate a [[forwarding agreement]] in each case where a message actually has to go through for the first time. (Existing recipes are to be searched before implicit ones.)

A cute trick to initialize the system so that it doesn't have to reply 4xx codes until agreements are finalized, which is likely to happen if the primary host is down, is to provide a list of hashed email addresses. That way, a backup MX may check that a given address actually exists, and accept it, being confident that the primary server will accept it in turn. The forwarding agreement will be negotiated when the primary (or a more preferred secondary) comes up. That circumstance more or less coincides with the moment when the cleartext address corresponding to the hashed entry becomes known at the server. Since provisions for accepting forwarding agreements from a backup MX should have been set up already at the primary's, we can regard as substantially irrelevant the short period of time while the first message for a given address remains stored in the backup MX's cache. (During that time, the server knows the email address without being bound by an agreement.)

Besides the list of hashes, the ''initialization data'', may contain regular expressions to account for subaddresses, prefixes, catch-all's, honeypots, etcetera. More meta data may be needed. Provisions to periodically refresh the initialization data are also needed. Changes in the DNS that add or remove MXes, or just change preferences, have to be dealt with.

End users should not be able to delete their forwarding agreement at a backup MX, unless they also delete their mailbox at the primary MX. Blocking such agreements, i.e. leaving an existing recipe in place while configuring it to reply ''551 User not local'', may result in some disruption and noncompliance. Such blocking may be disallowed by domain policies. At any rate, privacy concerned users will gain the ability to retrieve the effective list of servers where their email addresses are stored (a somewhat idealistic wish, until some marketing function will say otherwise.)

== See also ==
* [[boundary#Backup MXes]]
* [[forwarding recipe#Backup MXes]]
* The [http://www.imc.org/ietf-smtp/mail-archive/msg05696.html ietf-smtp thread] that inspired this page
* [[wp:MX record#The backup MX]]

== References ==
&lt;references/&gt;</text>
    <sha1>1cc10814f042ee56abe71cdcc74d3e9b60beaaa1</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>File:Forward.png</title>
  <ns>6</ns>
  <id>28</id>
  <revision>
    <id>1536</id>
    <timestamp>2009-10-28T18:46:16Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Simple forwarding illustration</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="30" xml:space="preserve">Simple forwarding illustration</text>
    <sha1>dc6bc7bd5244f041e7545a75f9c2a9d2c3cd3721</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>File:Normal-delivery.png</title>
  <ns>6</ns>
  <id>29</id>
  <revision>
    <id>1537</id>
    <timestamp>2009-10-28T18:52:11Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Normal (direct) message delivery</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="32" xml:space="preserve">Normal (direct) message delivery</text>
    <sha1>6ac2668319c3de4434d4e286bb769c08c9112d81</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>File:Backup-mx.png</title>
  <ns>6</ns>
  <id>30</id>
  <revision>
    <id>1538</id>
    <timestamp>2009-10-28T18:52:48Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Backup MX delivery mechanism</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="28" xml:space="preserve">Backup MX delivery mechanism</text>
    <sha1>f551dacfe709a94cb4d7c5f50131f6f96fc151ed</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>File:List.png</title>
  <ns>6</ns>
  <id>31</id>
  <revision>
    <id>1539</id>
    <timestamp>2009-10-28T18:53:44Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Depiction of mailing list explosion</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="35" xml:space="preserve">Depiction of mailing list explosion</text>
    <sha1>a466183c544dda5eca4119c8fb71a2c761f06018</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>standard behavior</title>
  <ns>0</ns>
  <id>32</id>
  <revision>
    <id>1540</id>
    <timestamp>2009-10-28T19:10:15Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>page creation (to be completed with images)</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="689" xml:space="preserve">'''Standard behavior''' accounts for simple store and forward mechanisms that have been devised long before privacy regulations. Here we describe the most usual patterns that a message may go through.

==Direct personal message==
[[File:Normal-delivery.png|300px|thumb|left|Normal delivery]] The normal delivery image is displayed to introduce the concept of a ''Message Submission Agent'' (MSA), a.k.a. outgoing mail server, which collects a message from an author, determines the destination server and sends the message to it. The recipient will find the message in the INBOX.
&lt;br style="clear:both" /&gt;

==External forwarding==


==Mailing lists and newsletter==

==External backup MX==</text>
    <sha1>af8c815161d379cddbb7d153055e96729ac5efb8</sha1>
  </revision>
  <revision>
    <id>1541</id>
    <parentid>1540</parentid>
    <timestamp>2009-10-29T18:32:28Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>add remaining illustrations and text</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5636" xml:space="preserve">'''Standard behavior''' accounts for simple store and forward mechanisms that have been devised long before privacy regulations. Here we describe the most usual patterns that a message may go through, highlighting the problem of managing personal data (a.k.a. personally identifiable data.)

==Direct personal message==
[[File:Normal-delivery.png|300px|thumb|left|Normal delivery]] The normal delivery image is displayed to introduce the concept of an '''MSA''' (''Message Submission Agent'', a.k.a. outgoing mail server) which collects a message from a sender, determines the relevant destination server, and sends the message there, where the recipient will find it.

It is assumed that users have an agreement with the mail domain that serve their addresses. That's implicit in the format ''&amp;lt;recipient@domain&amp;gt;'' of email addresses.
&lt;br style="clear:both" /&gt;

==External forwarding==
[[File:Forward.png|300px|thumb|left|Forwarding to a different mail domain]] The original destination &lt;u&gt;''rcpt@domain''&lt;/u&gt; is replaced with &lt;u&gt;''rcpt@other-domain''&lt;/u&gt; by the &lt;u&gt;forwarding server&lt;/u&gt;. The new address is someone's personal data, and its owner deserves full access to it.

We call this ''external'' to distinguish it from role accounts, e.g. ''sales@domain'' and similar forwarding of messages within the same server or mail domain. While for internal forwarding we may assume adequate agreements between users and their mail domains, external organizations require their own agreements. We are not much interested in formal pieces of paper, but rather in the effective ability of users to control how their addresses are used.

Vanity domains' email addresses solely exist for forwarding. In most such cases, they feature full blown web applications that allow users to control their addresses. However, simple ''.forward'' files do not. They are part of the recommended procedure for changing email address, which may well be considered a necessary part of the mail system.
&lt;br style="clear:both" /&gt;

==Newsletters and announcements==
[[File:List.png|300px|thumb|left|Newsletters and mailing lists]] Newsletters are the long established case where privacy rules get broken. Technically, they are the same as mailing lists. However, the semantics is very different. Most mailing list are very respectful of privacy: they require explicit user's subscription, which is double checked so that it is really difficult to subscribe someone else, and they regularly send unsubscribe instructions. Newsletters and single announcements are a means for advertising something, and only in a few cases they collect subscriptions regularly.

Senders submit the message to the list exploder for &lt;u&gt;''list@domain''&lt;/u&gt;. That is, they don't manually type addresses, nor select them from public directories, for each message they send. Rather, they maintain a database from which destination addresses can be extracted by the exploder using convenient criteria. Users shall be able to access the data records that concern them. However, seeking users' confirmation by sending them an email message upon insertion is grotesque, since message-sending is not yet confirmed.

Senders' requirement is to build those databases. In several cases, sending organizations lack the prestige, fame, and reputation for enticing users to subscribe spontaneously, and thus collect addresses in various ways. We are not much interested in ''how'' addresses are collected. However, there is a precise moment when an address is made available to an exploder, with given extraction criteria. An agreement with the subject must be sought after that moment, and before any message that matches those criteria is actually sent. Thus, automating this kind of agreement is apparently the kind of solution we seek.
&lt;br style="clear:both" /&gt;

==External backup MX==
[[File:Backup-mx.png|300px|thumb|left|Primary mail exchanger is unreachable, message is delivered through a backup MX]] It used to be rather common to have ''external'' backup MXes. These were machines configured to accept mail for a different domain, without being able to state the validity of its addresses. They were only used when the main (or primary) server experienced a network outage, and only kept any messages in a local queue until it became possible to deliver them.

Nowadays, organizations that operate on a single network have given up using backup MXes. Until networks work reliably, they are not needed. Old-style backup MXes accept messages destined to ''non-existent@domain'', and attempt to send them to the main server, with embarrassing behavior about delivery status notifications. Larger organizations distribute their users' data so that any server can determine whether a mailbox exists. If they are distributed evenly around the globe, their mail systems may work even in case solar flares tamper with telecommunications.

This problem has a common facet with that of newsletters. Assume a backup MX has been fed with a hashed list of addresses; that is, it can compute a one-way hash of any address so as to determine whether it is listed, without knowing them all. That can be set up at a third party's server without requiring special interaction with each subject, although proper notification is appropriate. When the backup MX learns of the existence of one of those addresses --after a positive lookup--it moves it from the hashed list and makes it available on a cleartext one: on performing such operation, it is in the same condition of a newsletter exploder acquiring a new address, therefore it can solve the problem by the same means.
&lt;br style="clear:both" /&gt;</text>
    <sha1>b99f889da49621db6ee14e36d93b503099dca65d</sha1>
  </revision>
  <revision>
    <id>1543</id>
    <parentid>1541</parentid>
    <timestamp>2009-10-31T11:10:34Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>add footnotes</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6170" xml:space="preserve">'''Standard behavior''' accounts for simple store and forward mechanisms that have been devised long before privacy regulations. Here we describe the most usual patterns that a message may go through, highlighting the problem of managing personal data (a.k.a. personally identifiable data.)

==Direct personal message==
[[File:Normal-delivery.png|300px|thumb|left|Normal delivery]] The normal delivery image is displayed to introduce the concept of an '''MSA''' (''Message Submission Agent'', a.k.a. outgoing mail server) which collects a message from a sender, determines the relevant destination server, and sends the message there, where the recipient will find it.

It is assumed that users have an agreement with the mail domain that serve their addresses. That's implicit in the format ''&amp;lt;recipient@domain&amp;gt;'' of email addresses.
&lt;br style="clear:both" /&gt;

==External forwarding==
[[File:Forward.png|300px|thumb|left|Forwarding to a different mail domain]] The original destination &lt;u&gt;''rcpt@domain''&lt;/u&gt; is replaced with &lt;u&gt;''rcpt@other-domain''&lt;/u&gt; by the &lt;u&gt;forwarding server&lt;/u&gt;. The new address is someone's personal data, and its owner deserves full access to it.

We call this ''external'' to distinguish it from role accounts, e.g. ''sales@domain'' and similar forwarding of messages within the same server or mail domain. While for internal forwarding we may assume adequate agreements between users and their mail domains, external organizations require their own agreements. We are not much interested in formal pieces of paper, but rather in the effective ability of users to control how their addresses are used.

Vanity domains' email addresses solely exist for forwarding. In most such cases, they feature full blown web applications that allow users to control their addresses. However, simple ''.forward'' files do not&lt;ref&gt;In a classical setting, ''.forward'' files live in users' home directories, and hence are under their complete control. Most current mail servers, however, work with ''virtual users'', an arrangement that allows better management and is safer for server's security. Access to ''.forward'' files is an oversight originating from the fact that the fundamental principle, that email addresses shall be under the complete control of their owners, although respected, was never made explicit in SMTP&lt;/ref&gt;. They are part of the recommended procedure for changing email address, which may well be considered a necessary part of the mail system.
&lt;br style="clear:both" /&gt;

==Newsletters and announcements==
[[File:List.png|300px|thumb|left|Newsletters and mailing lists]] Newsletters are the long established case where privacy rules get broken. Technically, they are the same as mailing lists. However, the semantics is very different. Most mailing list are very respectful of privacy: they require explicit user's subscription, which is double checked so that it is really difficult to subscribe someone else, and they regularly send unsubscribe instructions. Newsletters and single announcements are a means for advertising something, and only in a few cases they collect subscriptions regularly.

Senders submit the message to the list exploder for &lt;u&gt;''list@domain''&lt;/u&gt;. That is, they don't manually type addresses, nor select them from public directories, for each message they send. Rather, they maintain a database from which destination addresses can be extracted by the exploder using convenient criteria. Users shall be able to access the data records that concern them. However, seeking users' confirmation by sending them an email message upon insertion is grotesque, since message-sending is not yet confirmed.

Senders' requirement is to build those databases. In several cases, sending organizations lack the prestige, fame, and reputation for enticing users to subscribe spontaneously, and thus collect addresses in various ways. We are not much interested in ''how'' addresses are collected. However, there is a precise moment when an address is made available to an exploder, with given extraction criteria. An agreement with the subject must be sought after that moment, and before any message that matches those criteria is actually sent. Thus, automating this kind of agreement is apparently the kind of solution we seek.
&lt;br style="clear:both" /&gt;

==External backup MX==
[[File:Backup-mx.png|300px|thumb|left|Primary mail exchanger is unreachable, message is delivered through a backup MX]] It used to be rather common to have ''external'' backup MXes. These were machines configured to accept mail for a different domain, without being able to state the validity of its addresses. They were only used when the main (or primary) server experienced a network outage, and only kept any messages in a local queue until it became possible to deliver them.

Nowadays, organizations that operate on a single network have given up using backup MXes. Until networks work reliably, they are not needed. Old-style backup MXes accept messages destined to ''non-existent@domain'', and attempt to send them to the main server, with embarrassing behavior about delivery status notifications. Larger organizations distribute their users' data so that any server can determine whether a mailbox exists. If they are distributed evenly around the globe, their mail systems may work even in case solar flares tamper with telecommunications.

This problem has a common facet with that of newsletters. Assume a backup MX has been fed with a hashed list of addresses; that is, it can compute a one-way hash of any address so as to determine whether it is listed, without knowing them all. That can be set up at a third party's server without requiring special interaction with each subject, although proper notification is appropriate. When the backup MX learns of the existence of one of those addresses --after a positive lookup--it moves it from the hashed list and makes it available on a cleartext one: on performing such operation, it is in the same condition of a newsletter exploder acquiring a new address, therefore it can solve the problem by the same means.
&lt;br style="clear:both" /&gt;

==Footnotes==
&lt;references/&gt;</text>
    <sha1>fff8fd3a2481531578a28677f3fba72abfe700f7</sha1>
  </revision>
  <revision>
    <id>1544</id>
    <parentid>1543</parentid>
    <timestamp>2009-10-31T12:00:38Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Newsletters and announcements */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6673" xml:space="preserve">'''Standard behavior''' accounts for simple store and forward mechanisms that have been devised long before privacy regulations. Here we describe the most usual patterns that a message may go through, highlighting the problem of managing personal data (a.k.a. personally identifiable data.)

==Direct personal message==
[[File:Normal-delivery.png|300px|thumb|left|Normal delivery]] The normal delivery image is displayed to introduce the concept of an '''MSA''' (''Message Submission Agent'', a.k.a. outgoing mail server) which collects a message from a sender, determines the relevant destination server, and sends the message there, where the recipient will find it.

It is assumed that users have an agreement with the mail domain that serve their addresses. That's implicit in the format ''&amp;lt;recipient@domain&amp;gt;'' of email addresses.
&lt;br style="clear:both" /&gt;

==External forwarding==
[[File:Forward.png|300px|thumb|left|Forwarding to a different mail domain]] The original destination &lt;u&gt;''rcpt@domain''&lt;/u&gt; is replaced with &lt;u&gt;''rcpt@other-domain''&lt;/u&gt; by the &lt;u&gt;forwarding server&lt;/u&gt;. The new address is someone's personal data, and its owner deserves full access to it.

We call this ''external'' to distinguish it from role accounts, e.g. ''sales@domain'' and similar forwarding of messages within the same server or mail domain. While for internal forwarding we may assume adequate agreements between users and their mail domains, external organizations require their own agreements. We are not much interested in formal pieces of paper, but rather in the effective ability of users to control how their addresses are used.

Vanity domains' email addresses solely exist for forwarding. In most such cases, they feature full blown web applications that allow users to control their addresses. However, simple ''.forward'' files do not&lt;ref&gt;In a classical setting, ''.forward'' files live in users' home directories, and hence are under their complete control. Most current mail servers, however, work with ''virtual users'', an arrangement that allows better management and is safer for server's security. Access to ''.forward'' files is an oversight originating from the fact that the fundamental principle, that email addresses shall be under the complete control of their owners, although respected, was never made explicit in SMTP&lt;/ref&gt;. They are part of the recommended procedure for changing email address, which may well be considered a necessary part of the mail system.
&lt;br style="clear:both" /&gt;

==Newsletters and announcements==
[[File:List.png|300px|thumb|left|Newsletters and mailing lists]] Newsletters are the long established case where privacy rules get broken. Technically, they are the same as mailing lists. However, the semantics is very different. Most mailing list are very respectful of privacy: they require explicit user's subscription, which is double checked so that it is really difficult to subscribe someone else, and they regularly send unsubscribe instructions. Newsletters and single announcements are a means for advertising something, and only in a few cases they collect subscriptions regularly.

Senders submit the message to the list exploder for &lt;u&gt;''list@domain''&lt;/u&gt;. That is, they don't manually type addresses, nor select them from public directories, for each message they send. Rather, they maintain a database from which destination addresses can be extracted by the exploder using convenient criteria. Users shall be able to access the data records that concern them. However, seeking users' confirmation by sending them an email message upon insertion is grotesque, since message-sending is not yet confirmed.

Senders' requirement is to build those databases. In several cases, sending organizations lack the prestige, fame, and reputation for enticing users to subscribe spontaneously, and thus collect addresses in various ways. We are not much interested in ''how'' addresses are collected. However, there is a precise moment when an address is made available to an exploder, with given extraction criteria. An agreement with the subject must be sought after that moment, and before any message that matches those criteria is actually sent. Thus, automating this kind of agreement is apparently the kind of solution we seek.&lt;ref&gt;Users might configure their preferences, on their mail servers, specifying what they wish to do for a [[forwarding agreement]] proposal that makes their mailbox the target of a given message or series of messages. For example, they might specify, for any category of message, whether they wish to automatically deny or accept the agreement, and how they'd like to be notified of this fact. Categories of messages might be defined by means of ''Solicitation-keywords'', as defined in RFC 3865.&lt;/ref&gt;
&lt;br style="clear:both" /&gt;

==External backup MX==
[[File:Backup-mx.png|300px|thumb|left|Primary mail exchanger is unreachable, message is delivered through a backup MX]] It used to be rather common to have ''external'' backup MXes. These were machines configured to accept mail for a different domain, without being able to state the validity of its addresses. They were only used when the main (or primary) server experienced a network outage, and only kept any messages in a local queue until it became possible to deliver them.

Nowadays, organizations that operate on a single network have given up using backup MXes. Until networks work reliably, they are not needed. Old-style backup MXes accept messages destined to ''non-existent@domain'', and attempt to send them to the main server, with embarrassing behavior about delivery status notifications. Larger organizations distribute their users' data so that any server can determine whether a mailbox exists. If they are distributed evenly around the globe, their mail systems may work even in case solar flares tamper with telecommunications.

This problem has a common facet with that of newsletters. Assume a backup MX has been fed with a hashed list of addresses; that is, it can compute a one-way hash of any address so as to determine whether it is listed, without knowing them all. That can be set up at a third party's server without requiring special interaction with each subject, although proper notification is appropriate. When the backup MX learns of the existence of one of those addresses --after a positive lookup--it moves it from the hashed list and makes it available on a cleartext one: on performing such operation, it is in the same condition of a newsletter exploder acquiring a new address, therefore it can solve the problem by the same means.
&lt;br style="clear:both" /&gt;

==Footnotes==
&lt;references/&gt;</text>
    <sha1>881c473c464ddf65ac3203c0bbded847382fb633</sha1>
  </revision>
  <revision>
    <id>1545</id>
    <parentid>1544</parentid>
    <timestamp>2009-11-11T18:43:53Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Direct personal message */ explain simplified labels</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6786" xml:space="preserve">'''Standard behavior''' accounts for simple store and forward mechanisms that have been devised long before privacy regulations. Here we describe the most usual patterns that a message may go through, highlighting the problem of managing personal data (a.k.a. personally identifiable data.)

==Direct personal message==
[[File:Normal-delivery.png|300px|thumb|left|Normal delivery]] The normal delivery image is displayed to introduce the concepts of '''MSA''' (''Message Submission Agent'', a.k.a. outgoing mail server) and '''MX''' (''Mail eXchanger''). All servers are labeled according to the first role they play along the illustrated message path. For example, the MSA also acts as a transmitter, as it determines the relevant destination server, and sends the message there.

It is assumed that users have an agreement with the mail domain that serves their addresses. That's implicit in the format ''&amp;lt;recipient@domain&amp;gt;'' of email addresses.
&lt;br style="clear:both" /&gt;

==External forwarding==
[[File:Forward.png|300px|thumb|left|Forwarding to a different mail domain]] The original destination &lt;u&gt;''rcpt@domain''&lt;/u&gt; is replaced with &lt;u&gt;''rcpt@other-domain''&lt;/u&gt; by the &lt;u&gt;forwarding server&lt;/u&gt;. The new address is someone's personal data, and its owner deserves full access to it.

We call this ''external'' to distinguish it from role accounts, e.g. ''sales@domain'' and similar forwarding of messages within the same server or mail domain. While for internal forwarding we may assume adequate agreements between users and their mail domains, external organizations require their own agreements. We are not much interested in formal pieces of paper, but rather in the effective ability of users to control how their addresses are used.

Vanity domains' email addresses solely exist for forwarding. In most such cases, they feature full blown web applications that allow users to control their addresses. However, simple ''.forward'' files do not&lt;ref&gt;In a classical setting, ''.forward'' files live in users' home directories, and hence are under their complete control. Most current mail servers, however, work with ''virtual users'', an arrangement that allows better management and is safer for server's security. Access to ''.forward'' files is an oversight originating from the fact that the fundamental principle, that email addresses shall be under the complete control of their owners, although respected, was never made explicit in SMTP&lt;/ref&gt;. They are part of the recommended procedure for changing email address, which may well be considered a necessary part of the mail system.
&lt;br style="clear:both" /&gt;

==Newsletters and announcements==
[[File:List.png|300px|thumb|left|Newsletters and mailing lists]] Newsletters are the long established case where privacy rules get broken. Technically, they are the same as mailing lists. However, the semantics is very different. Most mailing list are very respectful of privacy: they require explicit user's subscription, which is double checked so that it is really difficult to subscribe someone else, and they regularly send unsubscribe instructions. Newsletters and single announcements are a means for advertising something, and only in a few cases they collect subscriptions regularly.

Senders submit the message to the list exploder for &lt;u&gt;''list@domain''&lt;/u&gt;. That is, they don't manually type addresses, nor select them from public directories, for each message they send. Rather, they maintain a database from which destination addresses can be extracted by the exploder using convenient criteria. Users shall be able to access the data records that concern them. However, seeking users' confirmation by sending them an email message upon insertion is grotesque, since message-sending is not yet confirmed.

Senders' requirement is to build those databases. In several cases, sending organizations lack the prestige, fame, and reputation for enticing users to subscribe spontaneously, and thus collect addresses in various ways. We are not much interested in ''how'' addresses are collected. However, there is a precise moment when an address is made available to an exploder, with given extraction criteria. An agreement with the subject must be sought after that moment, and before any message that matches those criteria is actually sent. Thus, automating this kind of agreement is apparently the kind of solution we seek.&lt;ref&gt;Users might configure their preferences, on their mail servers, specifying what they wish to do for a [[forwarding agreement]] proposal that makes their mailbox the target of a given message or series of messages. For example, they might specify, for any category of message, whether they wish to automatically deny or accept the agreement, and how they'd like to be notified of this fact. Categories of messages might be defined by means of ''Solicitation-keywords'', as defined in RFC 3865.&lt;/ref&gt;
&lt;br style="clear:both" /&gt;

==External backup MX==
[[File:Backup-mx.png|300px|thumb|left|Primary mail exchanger is unreachable, message is delivered through a backup MX]] It used to be rather common to have ''external'' backup MXes. These were machines configured to accept mail for a different domain, without being able to state the validity of its addresses. They were only used when the main (or primary) server experienced a network outage, and only kept any messages in a local queue until it became possible to deliver them.

Nowadays, organizations that operate on a single network have given up using backup MXes. Until networks work reliably, they are not needed. Old-style backup MXes accept messages destined to ''non-existent@domain'', and attempt to send them to the main server, with embarrassing behavior about delivery status notifications. Larger organizations distribute their users' data so that any server can determine whether a mailbox exists. If they are distributed evenly around the globe, their mail systems may work even in case solar flares tamper with telecommunications.

This problem has a common facet with that of newsletters. Assume a backup MX has been fed with a hashed list of addresses; that is, it can compute a one-way hash of any address so as to determine whether it is listed, without knowing them all. That can be set up at a third party's server without requiring special interaction with each subject, although proper notification is appropriate. When the backup MX learns of the existence of one of those addresses --after a positive lookup--it moves it from the hashed list and makes it available on a cleartext one: on performing such operation, it is in the same condition of a newsletter exploder acquiring a new address, therefore it can solve the problem by the same means.
&lt;br style="clear:both" /&gt;

==Footnotes==
&lt;references/&gt;</text>
    <sha1>c1dd97ff95554a2f2407fc05604e81fe105b33c7</sha1>
  </revision>
  <revision>
    <id>1546</id>
    <parentid>1545</parentid>
    <timestamp>2010-07-17T16:22:35Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>rephrase, add conclusions</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7349" xml:space="preserve">'''Standard behavior''' illustrates email simple store and forward mechanisms, that have been devised long before privacy regulations. Here we describe the most usual patterns that a message may go through, highlighting the problem of managing personal data, a.k.a. personally identifiable data.

Except for the first case, direct delivering, ''store and forward'' involves multiple parties, and thereby involves privacy concerns.

==Direct personal message==
[[File:Normal-delivery.png|300px|thumb|left|Normal delivery]] Normal delivery accounts for the majority of messages. The illustration introduces the concepts of '''MSA''' (''Message Submission Agent'', a.k.a. outgoing mail server) and '''MX''' (''Mail eXchanger'', a.k.a. incoming mail server). All servers are labeled according to the first role they play along the illustrated message path. For example, the MSA also acts as a transmitter, as it determines the relevant destination server, and sends the message there.

The very format ''&amp;lt;recipient@domain&amp;gt;'' of email addresses implies there is an agreement between a recipient and the domain. It is assumed that such agreements cover any privacy concern.
&lt;br style="clear:both" /&gt;

==External forwarding==
[[File:Forward.png|300px|thumb|left|Forwarding to a different mail domain]] The original destination &lt;u&gt;''rcpt@domain''&lt;/u&gt; is replaced with &lt;u&gt;''rcpt@other-domain''&lt;/u&gt; by the &lt;u&gt;forwarding server&lt;/u&gt;. The new address is someone's personal data, and its owner deserves full access to it.

We call this ''external'' to distinguish it from role accounts, e.g. ''sales@domain'' and similar forwarding of messages within the same server or mail domain. While for internal forwarding we may assume adequate agreements between users and their mail domains, external organizations require their own agreements. We are not much interested in formal pieces of paper, but rather in the effective ability of users to control how their addresses are used.

Vanity domains' email addresses solely exist for forwarding. In most such cases, they feature full blown web applications that allow users to control their addresses. However, simple ''.forward'' files do not&lt;ref&gt;In a classical setting, ''.forward'' files live in users' home directories, and hence are under their complete control. Most current mail servers, however, work with ''virtual users'', an arrangement that allows better management and is safer for server's security. Access to ''.forward'' files is an oversight originating from the fact that the fundamental principle, that email addresses shall be under the complete control of their owners, although respected, was never made explicit in SMTP&lt;/ref&gt;. They are part of the recommended procedure for changing email address, which may well be considered a necessary part of the mail system.
&lt;br style="clear:both" /&gt;

==Newsletters and announcements==
[[File:List.png|300px|thumb|left|Newsletters and mailing lists]] Newsletters are the long established case where privacy rules get broken. Technically, they are the same as mailing lists. However, the semantics is very different. Most mailing list are very respectful of privacy: they require explicit user's subscription, which is double checked so that it is really difficult to subscribe someone else, and they regularly send unsubscribe instructions. Newsletters and single announcements are a means for advertising something, and only in a few cases they collect subscriptions regularly.

Authors submit the message to the list exploder for &lt;u&gt;''list@domain''&lt;/u&gt;. That is, they don't manually type addresses, nor select them from public directories, for each message they send. Rather, they maintain a database from which destination addresses can be extracted by the exploder using convenient criteria. Users shall be able to access the data records that concern them. However, seeking users' confirmation by sending them an email message upon insertion is grotesque, since message-sending is not yet confirmed.

Senders' requirement is to build those databases. In several cases, sending organizations lack the prestige, fame, and reputation for enticing users to subscribe spontaneously, and thus collect addresses in various ways. We are not much interested in ''how'' addresses are collected. However, there is a precise moment when an address is made available to an exploder, with given extraction criteria, a.k.a. profiles. An agreement with the subject must be sought after that moment, and before any message that matches those criteria is actually sent. Thus, automating this kind of agreement is apparently the kind of solution we seek.&lt;ref&gt;Users might configure their preferences, on their mail servers, specifying what they wish to do for a [[forwarding agreement]] proposal that makes their mailbox the target of a given message or series of messages. For example, they might specify, for any category of message, whether they wish to automatically deny or accept the agreement, and how they'd like to be notified of this fact. Categories of messages might be defined by means of ''Solicitation-keywords'', as defined in RFC 3865.&lt;/ref&gt;
&lt;br style="clear:both" /&gt;

==External backup MX==
[[File:Backup-mx.png|300px|thumb|left|Primary mail exchanger is unreachable, message is delivered through a backup MX]] It used to be rather common to have ''external'' backup MXes. These were machines configured to accept mail for a different domain, without being able to state the validity of its addresses. They should only be used when the main (or primary) server experiences a network outage.

Nowadays, organizations that operate on a single network have given up using backup MXes. Until networks work reliably, they are not needed. Old-style backup MXes accept messages destined to ''non-existent@domain'', and attempt to send them to the main server, with embarrassing behavior about delivery status notifications. Larger organizations distribute their users' data so that any server can determine whether a mailbox exists. If they are distributed evenly around the globe, their mail systems may work even in case solar flares tamper with telecommunications.

Backup MXes operated by 3rd parties pose a problem that has a common facet with that of newsletters. Assume a backup MX has been fed with a hashed list of addresses; that is, it can compute a one-way hash of any address so as to determine whether it is listed. Since addresses are hidden, such feed doesn't require special interaction with each subject, although proper notification is appropriate. When the backup MX learns of the existence of one of those addresses --after a positive lookup-- it moves it from the hashed list and makes it available on a cleartext one: on performing such operation, it is in the same condition of a newsletter exploder acquiring a new address, therefore it can solve the problem by the same means.
&lt;br style="clear:both" /&gt;

==Conclusions==
Getting into an agreement would not be a tough procedure if there is a standard way to automate it.  The [[solution proposed]] provides for procedures to automatically negotiate agreements, and manage the required passwords for ''SMTP Authentication''.  As a result, MX servers will have lists of effective agreements, that they can put in the hands of the corresponding subjects.

==Footnotes==
&lt;references/&gt;</text>
    <sha1>dc66c0730901e01102a1b60abcc5f6a63acae572</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>Main Page</title>
  <ns>0</ns>
  <id>1</id>
  <revision>
    <id>1542</id>
    <parentid>1464</parentid>
    <timestamp>2009-10-29T18:45:57Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Add executive summary</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="1396" xml:space="preserve">'''This web site''' is dedicated to the analysis of current forwarding practices and a possible solution that is compliant with privacy rules. An implementation will hopefully be proposed at a further time.

== The problem ==
Our [[standard behavior]] page gives an executive summary of current mail forwarding mechanisms, highlighting where the problem occurs. A rather technical definition of [[forwarding]] is also given.

Savage forwarding produces quite some shortcomings:
* Recipients have no means to directly control the forwarding mechanism.
* Responsibility for injecting spam becomes ambiguous.
* Bounces may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

== The solution: Standardize forwarding practices ==
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?</text>
    <sha1>2f435ed3707ebc33183084984b03471fd2b1f9ce</sha1>
  </revision>
</page>
<page arvcontinue="20081228173347|1505">
  <title>FixForwarding:Terms of Service</title>
  <ns>4</ns>
  <id>36</id>
  <revision>
    <id>1555</id>
    <timestamp>2010-07-21T18:05:17Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Create page</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="671" xml:space="preserve">FixForwarding.org welcomes any contribution that improves this wiki.  However, in order to avoid spam, anonymous editing is disabled and creation of new accounts requires confirmation.

== Account Requests ==
Please choose an non-existing ''Username'' and a valid email address.  You'll have to confirm it by email before I'll get a notice about your request.

Your real name and a "biography" of at least a couple of words are also required.  Whatever you write as biography will become your ''User:'' page, linked from the ''Page hystory'' of any page you'll write.  Possibly, repeat your real name there.

Anything you write is subject to [[FixForwarding:Copyrights]].</text>
    <sha1>35ffa1bce3925a310f82db6627371aecfe98696d</sha1>
  </revision>
</page>
<page arvcontinue="20101017125844|1559">
  <title>forwarding agreement</title>
  <ns>0</ns>
  <id>11</id>
  <revision>
    <id>1559</id>
    <parentid>1552</parentid>
    <timestamp>2010-10-17T12:58:44Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* category */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8277" xml:space="preserve">A '''forwarding agreement''' is the procedural data that matches a [[forwarding recipe]]. It contains an agreement-ID and a password, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

== Doubly linked vs. singly linked lists ==
Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a ''singly linked list''. Forwarding agreements transform that into a ''doubly linked list''. (See [[wp:Linked list]].)

== Data fields ==

=== agreement-ID ===
The ''agreement-ID'' may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for SMTP Authentication. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

=== forwarder-ID ===
The ''forwarder-ID'' identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

=== category ===
An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, ''Mailing Lists and Aliases''. The ''category'' identifies what type of forwarding recipe corresponds to the agreement. The recipe can be ''static'', i.e. manually edited configuration data, or dynamic. A tentative list of categories is as follows:
* single recipient static,
* multiple recipient static,
* mailing list,
* newsletter,
* backup MX.

Sometimes static recipes can be edited using web forms or other remote mechanisms. The key difference is that static recipes allow a single user with enough permissions to edit multiple addresses at once, e.g. by providing a comma separated list. Dynamic recipes allow to independently add/delete single addresses without even letting the relevant user know whether there are more addresses on the list.

Mailing lists have a time-honored mechanism to subscribe/unsubscribe by email, web form management has been added on top of that, and the software designed to manage forwarding agreements may act compliantly. Any list that is not, strictly speaking, a ''mailing list'', is a newsletter.

The category is not supposed to change during an agreement's life-cycle, thus some of the above distinctions may be dropped.

=== user-ID ===
The ''user-ID'' identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

''URL'' and ''policy'' are described below.

== Establishing a forwarding agreement ==
The sender has to know that it is [[forwarding]] a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the ''-f'' command switch as described [[forwarding recipe#Envelope sender tweak|here]].

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

=== Triple handshake ===
#When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
#Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
#If the previous step concluded successfully, the forwarder can now visit the completion URL and set a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

=== URLs ===
All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP or REST request/response pages under HTTPS transport. An advantage of using an existing framework is that it avoids having to specify any encoding, multiple lines syntax, and similar kind of stuff; experience published about NETCONF can be used as a guideline, see RFC 5381. Lisa does not like SOAP[http://nih.blogspot.com/2008/09/ive-been-asked-lot-about-use-of-soap-in.html], REST looks simpler[http://blog.feedly.com/2009/03/03/jsonrest-vs-xmlsoap/]. (See also [http://www.ietf.org/proceedings/07dec/slides/xmltut-1.pdf Using XML in Internet Protocols].) HTTPS as a transport allows secure password exchange; in addition, the certificate and its signing authority can be taken into account when deciding to grant the agreement (but see also [[policy negotiation URL#Credentials and cryptographic support|Credentials and cryptographic support]].) SOAP has further security options and WS-* features, but for the time being they don't seem necessary.

We define the following URLs:
* the [[EHLO advertised URL]],
* the [[policy negotiation URL]] at the forwarder's, and
* the [[completion URL]].

The first and last ones are served by the target MTA.

== Using and maintaining agreements ==
An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for each recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender's must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail addresses that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. Alternatively, static recipes may be disabled causing the relevant server to supply responses like
&lt;pre&gt;
551  User not local; please try &amp;lt;forward-path&amp;gt;
&lt;/pre&gt;

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

== Policy considerations ==
For ''static'' agreements, the policy shall prescribe what [[boundary filter]]s the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SASL mechanism being used with SMTP Authentication, the password may have to be changed more or less often.

In addition, the [[forwarding recipe]] policy must be matched.</text>
    <sha1>e63acc8d3628d4d5e4230339d6ca47574f8f6c64</sha1>
  </revision>
</page>
<page arvcontinue="20101017125844|1559">
  <title>Main Page</title>
  <ns>0</ns>
  <id>1</id>
  <revision>
    <id>1560</id>
    <parentid>1542</parentid>
    <timestamp>2011-08-02T18:18:03Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>rewrite</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4731" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on on the ''list exploder''.  Rather than typing addresses, or retrieving them interactively from a personal or public address book, the sender sends to a ''pseudo-mailbox'' that the list exploder will use to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best replacement to email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify each of them,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses, and
* better anti-spam filtering by whitelisting legitimate messages.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>6fdf3e49bd07ac3e80319395a04740eb360ea1bd</sha1>
  </revision>
  <revision>
    <id>1561</id>
    <parentid>1560</parentid>
    <timestamp>2011-08-02T18:25:30Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* The problem */ add detection of illegal disclosures</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4791" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on on the ''list exploder''.  Rather than typing addresses, or retrieving them interactively from a personal or public address book, the sender sends to a ''pseudo-mailbox'' that the list exploder will use to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best replacement to email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify each of them,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses, and
* better anti-spam filtering by whitelisting legitimate messages.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>ecdf23564a3730804421109f3319e61e51173474</sha1>
  </revision>
  <revision>
    <id>1562</id>
    <parentid>1561</parentid>
    <timestamp>2011-08-02T18:27:32Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* A consent-exchange Internet protocol for email users */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4922" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on on the ''list exploder''.  Rather than typing addresses, or retrieving them interactively from a personal or public address book, the sender sends to a ''pseudo-mailbox'' that the list exploder will use to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best replacement to email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regard the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify each of them,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses, and
* better anti-spam filtering by whitelisting legitimate messages.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>1c89d87add7a619b9e4b79cc2435e2473cc48fd3</sha1>
  </revision>
  <revision>
    <id>1563</id>
    <parentid>1562</parentid>
    <timestamp>2011-08-02T18:29:48Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* A consent-exchange Internet protocol for email users */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4923" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on on the ''list exploder''.  Rather than typing addresses, or retrieving them interactively from a personal or public address book, the sender sends to a ''pseudo-mailbox'' that the list exploder will use to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best replacement to email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify each of them,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses, and
* better anti-spam filtering by whitelisting legitimate messages.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>6f3ea86772c97b5c0f307bd57f3bab794aaac68d</sha1>
  </revision>
  <revision>
    <id>1564</id>
    <parentid>1563</parentid>
    <timestamp>2011-08-02T18:32:31Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* The problem */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="4914" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify each of them,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses, and
* better anti-spam filtering by whitelisting legitimate messages.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>7cd67ca982f996aa80a799b2b0cdb84b4468392f</sha1>
  </revision>
  <revision>
    <id>1566</id>
    <parentid>1564</parentid>
    <timestamp>2011-11-16T12:18:57Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Anti-spam effect */ new section</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5348" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify each of them,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses, and
* better anti-spam filtering by whitelisting legitimate messages.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>f5b79be3084468def877e07fee5f2d4da80d9ade</sha1>
  </revision>
  <revision>
    <id>1567</id>
    <parentid>1566</parentid>
    <timestamp>2011-11-25T09:58:11Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>add Rationale section</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5693" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify each of them,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses, and
* better anti-spam filtering by whitelisting legitimate messages.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>c8cd105d77b862cb7d75dda075337498c8dc9fde</sha1>
  </revision>
  <revision>
    <id>1568</id>
    <parentid>1567</parentid>
    <timestamp>2011-12-08T18:38:24Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Rationale */ mention the Information Age</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5792" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the premise for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify each of them,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses, and
* better anti-spam filtering by whitelisting legitimate messages.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>27b3b49d5fbfdba270c4739df10473d631c9525b</sha1>
  </revision>
  <revision>
    <id>1569</id>
    <parentid>1568</parentid>
    <timestamp>2011-12-08T20:06:09Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* A consent-exchange Internet protocol for email users */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5844" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the premise for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>af98f999b22673222daf41b4b3e53956a9859209</sha1>
  </revision>
  <revision>
    <id>1570</id>
    <parentid>1569</parentid>
    <timestamp>2011-12-08T20:14:22Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* The problem */ inequitably hindered as 1st bullet</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5987" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the premise for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>0d46ee0fee4c78e3803e3850e17e03468a62b80c</sha1>
  </revision>
  <revision>
    <id>1571</id>
    <parentid>1570</parentid>
    <timestamp>2011-12-26T11:13:44Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Triple Opt-In */ new section</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7146" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the premise for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' is a refinement of double opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to interact with each other.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>7a937e5dab1bcebae08e510ddc8b77d1422e68a5</sha1>
  </revision>
  <revision>
    <id>1572</id>
    <parentid>1571</parentid>
    <timestamp>2011-12-26T11:29:32Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Triple Opt-In */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7143" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the premise for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' is a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to interact with each other.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>33eb2062556f654220d6660fa058f36ce2097ff6</sha1>
  </revision>
  <revision>
    <id>1573</id>
    <parentid>1572</parentid>
    <timestamp>2011-12-26T11:31:37Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Triple Opt-In */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7145" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the premise for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' is a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>96f0313e3bd605b33dc5300a9fbfe9cf9e696b39</sha1>
  </revision>
  <revision>
    <id>1575</id>
    <parentid>1573</parentid>
    <timestamp>2012-12-11T11:11:52Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* The problem */ typo</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7142" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the premise for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' is a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>0065eb5872c8d17d83a1737de9da1dbe76cf9992</sha1>
  </revision>
  <revision>
    <id>1581</id>
    <parentid>1575</parentid>
    <timestamp>2013-04-22T13:40:55Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* The problem */ eIAS as a method to acquire consent?</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7431" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the premise for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

Update: data subject's consent could by acquired by means of a ''trust service provider'' according to [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2012:0238:FIN:EN:HTML eIAS proposal] and [http://ameliaandersdotter.eu/eid-and-trust-services-regulation/ amendment] thereof.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' is a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>f83228efde4411f66dc206e457540168bd744b5e</sha1>
  </revision>
  <revision>
    <id>1582</id>
    <parentid>1581</parentid>
    <timestamp>2013-12-17T14:40:47Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Triple Opt-In */ Criticism</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8008" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the premise for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

Update: data subject's consent could by acquired by means of a ''trust service provider'' according to [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2012:0238:FIN:EN:HTML eIAS proposal] and [http://ameliaandersdotter.eu/eid-and-trust-services-regulation/ amendment] thereof.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' is a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

===Criticism===
A reason to avoid the term ''triple opt-in'' altogether is that it is being used with a different (marketing) meaning, see e.g. [http://www.mmaglobal.com/wiki/triple-opt here].

An additional weakness is that a user's mail server can just be grateful for the information supplied, and decline to send a proper acknowledge to the wannabe sender.  Since the sender is doing this in order to have such legal proof of its conduct, lazy mailbox provider behavior can hamper a naive implementation.

Let me name this [[Water tight opt-in]], following David Hofstee.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>395a806141b5e761ccc9cf43c4c2a9f99d1a1408</sha1>
  </revision>
  <revision>
    <id>1594</id>
    <parentid>1582</parentid>
    <timestamp>2014-04-26T09:57:50Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* DNS declaration of mailing list */ new section</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8633" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the premise for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

Update: data subject's consent could by acquired by means of a ''trust service provider'' according to [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2012:0238:FIN:EN:HTML eIAS proposal] and [http://ameliaandersdotter.eu/eid-and-trust-services-regulation/ amendment] thereof.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' is a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

===Criticism===
A reason to avoid the term ''triple opt-in'' altogether is that it is being used with a different (marketing) meaning, see e.g. [http://www.mmaglobal.com/wiki/triple-opt here].

An additional weakness is that a user's mail server can just be grateful for the information supplied, and decline to send a proper acknowledge to the wannabe sender.  Since the sender is doing this in order to have such legal proof of its conduct, lazy mailbox provider behavior can hamper a naive implementation.

Let me name this [[Water tight opt-in]], following David Hofstee.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

== DNS declaration of mailing list ==
Yet another idea is to use DNS RRs to declare that a given email address is a mailing list (suggested by John Levine [http://www.ietf.org/mail-archive/web/ietf-822/current/msg06714.html here]).  It is exemplified as

  &amp;lt;hash of ietf-822&amp;gt;._mayresign.ietf.org TXT "v=MR1; d=ietf.org"

That says the ietf-822 at ietf.org list is signed with d=ietf.org.  If a domain contains only mailing lists, you can use a wildcard

  *._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"

A submission server can then derive that one of its users is a subscriber of a list declared that way.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>5d33060beedd3c5210bcb299f843e721fec5058f</sha1>
  </revision>
  <revision>
    <id>1595</id>
    <parentid>1594</parentid>
    <timestamp>2017-12-01T12:07:23Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Rationale */ s/premise/precondition/</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8638" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the precondition for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

Update: data subject's consent could by acquired by means of a ''trust service provider'' according to [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2012:0238:FIN:EN:HTML eIAS proposal] and [http://ameliaandersdotter.eu/eid-and-trust-services-regulation/ amendment] thereof.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' is a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

===Criticism===
A reason to avoid the term ''triple opt-in'' altogether is that it is being used with a different (marketing) meaning, see e.g. [http://www.mmaglobal.com/wiki/triple-opt here].

An additional weakness is that a user's mail server can just be grateful for the information supplied, and decline to send a proper acknowledge to the wannabe sender.  Since the sender is doing this in order to have such legal proof of its conduct, lazy mailbox provider behavior can hamper a naive implementation.

Let me name this [[Water tight opt-in]], following David Hofstee.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

== DNS declaration of mailing list ==
Yet another idea is to use DNS RRs to declare that a given email address is a mailing list (suggested by John Levine [http://www.ietf.org/mail-archive/web/ietf-822/current/msg06714.html here]).  It is exemplified as

  &amp;lt;hash of ietf-822&amp;gt;._mayresign.ietf.org TXT "v=MR1; d=ietf.org"

That says the ietf-822 at ietf.org list is signed with d=ietf.org.  If a domain contains only mailing lists, you can use a wildcard

  *._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"

A submission server can then derive that one of its users is a subscriber of a list declared that way.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>189ecbbe9aac70650450c95a8d96e718fb4e9c02</sha1>
  </revision>
  <revision>
    <id>1596</id>
    <parentid>1595</parentid>
    <timestamp>2017-12-01T12:11:25Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* The problem */ s/dishonoring/betraying/</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8636" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the precondition for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby betraying any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

Update: data subject's consent could by acquired by means of a ''trust service provider'' according to [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2012:0238:FIN:EN:HTML eIAS proposal] and [http://ameliaandersdotter.eu/eid-and-trust-services-regulation/ amendment] thereof.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' is a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

===Criticism===
A reason to avoid the term ''triple opt-in'' altogether is that it is being used with a different (marketing) meaning, see e.g. [http://www.mmaglobal.com/wiki/triple-opt here].

An additional weakness is that a user's mail server can just be grateful for the information supplied, and decline to send a proper acknowledge to the wannabe sender.  Since the sender is doing this in order to have such legal proof of its conduct, lazy mailbox provider behavior can hamper a naive implementation.

Let me name this [[Water tight opt-in]], following David Hofstee.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

== DNS declaration of mailing list ==
Yet another idea is to use DNS RRs to declare that a given email address is a mailing list (suggested by John Levine [http://www.ietf.org/mail-archive/web/ietf-822/current/msg06714.html here]).  It is exemplified as

  &amp;lt;hash of ietf-822&amp;gt;._mayresign.ietf.org TXT "v=MR1; d=ietf.org"

That says the ietf-822 at ietf.org list is signed with d=ietf.org.  If a domain contains only mailing lists, you can use a wildcard

  *._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"

A submission server can then derive that one of its users is a subscriber of a list declared that way.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>b33fbf6a9c64380ed7454be6673b36bcb71296a1</sha1>
  </revision>
  <revision>
    <id>1597</id>
    <parentid>1596</parentid>
    <timestamp>2017-12-01T12:58:12Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* The problem */ change eIDAS links</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="8793" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the precondition for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby betraying any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

There is an EU regulation, [[wp:eIDAS]], a standard developed for transactions in the EU single market.  It can be considered a sort of S/MIME extension; that is, it features centralized key management -the main difference w.r.t. the PGP suite.  That way, data subject's consent could by acquired by means of a ''trust service provider'' according to regulation.  A statement like this would be consistent with law-regulated privacy protection.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' is a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

===Criticism===
A reason to avoid the term ''triple opt-in'' altogether is that it is being used with a different (marketing) meaning, see e.g. [http://www.mmaglobal.com/wiki/triple-opt here].

An additional weakness is that a user's mail server can just be grateful for the information supplied, and decline to send a proper acknowledge to the wannabe sender.  Since the sender is doing this in order to have such legal proof of its conduct, lazy mailbox provider behavior can hamper a naive implementation.

Let me name this [[Water tight opt-in]], following David Hofstee.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

== DNS declaration of mailing list ==
Yet another idea is to use DNS RRs to declare that a given email address is a mailing list (suggested by John Levine [http://www.ietf.org/mail-archive/web/ietf-822/current/msg06714.html here]).  It is exemplified as

  &amp;lt;hash of ietf-822&amp;gt;._mayresign.ietf.org TXT "v=MR1; d=ietf.org"

That says the ietf-822 at ietf.org list is signed with d=ietf.org.  If a domain contains only mailing lists, you can use a wildcard

  *._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"

A submission server can then derive that one of its users is a subscriber of a list declared that way.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>8f738a73cbebaf3960556582c03e34ea0fc45d12</sha1>
  </revision>
  <revision>
    <id>1598</id>
    <parentid>1597</parentid>
    <timestamp>2018-03-14T17:34:31Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* A consent-exchange Internet protocol for email users */ update 2018</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="11392" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the precondition for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby betraying any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

There is an EU regulation, [[wp:eIDAS]], a standard developed for transactions in the EU single market.  It can be considered a sort of S/MIME extension; that is, it features centralized key management -the main difference w.r.t. the PGP suite.  That way, data subject's consent could by acquired by means of a ''trust service provider'' according to regulation.  A statement like this would be consistent with law-regulated privacy protection.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' is a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

===Criticism===
A reason to avoid the term ''triple opt-in'' altogether is that it is being used with a different (marketing) meaning, see e.g. [http://www.mmaglobal.com/wiki/triple-opt here].

An additional weakness is that a user's mail server can just be grateful for the information supplied, and decline to send a proper acknowledge to the wannabe sender.  Since the sender is doing this in order to have such legal proof of its conduct, lazy mailbox provider behavior can hamper a naive implementation.

Let me name this [[Water tight opt-in]], following David Hofstee.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

=== Update 2018 ===
The new [http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679 REGULATION 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL] of 27 April 2016, article 68, states (my enhancing):
&lt;blockquote&gt;
To further strengthen the control over his or her own data, where the processing of personal data is carried out by automated means, the data subject should also be allowed to receive personal data concerning him or her which he or she has provided to a controller in a structured, commonly used, machine-readable and interoperable format, and to transmit it to another controller. '''Data controllers should be encouraged to develop interoperable formats that enable data portability.''' That right should apply where the data subject provided the personal data on the basis of his or her consent or the processing is necessary for the performance of a contract. It should not apply where processing is based on a legal ground other than consent or contract. By its very nature, that right should not be exercised against controllers processing personal data in the exercise of their public duties. It should therefore not apply where the processing of the personal data is necessary for compliance with a legal obligation to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of an official authority vested in the controller. The data subject's right to transmit or receive personal data concerning him or her should not create an obligation for the controllers to adopt or maintain processing systems which are technically compatible. Where, in a certain set of personal data, more than one data subject is concerned, the right to receive the personal data should be without prejudice to the rights and freedoms of other data subjects in accordance with this Regulation. Furthermore, that right should not prejudice the right of the data subject to obtain the erasure of personal data and the limitations of that right as set out in this Regulation and should, in particular, not imply the erasure of personal data concerning the data subject which have been provided by him or her for the performance of a contract to the extent that and for as long as the personal data are necessary for the performance of that contract. Where technically feasible, the data subject should have the right to have the personal data transmitted directly from one controller to another.
&lt;/blockquote&gt;

Besides all the limitations intended to safeguard data controllers, it clearly calls for such a standard.

== DNS declaration of mailing list ==
Yet another idea is to use DNS RRs to declare that a given email address is a mailing list (suggested by John Levine [http://www.ietf.org/mail-archive/web/ietf-822/current/msg06714.html here]).  It is exemplified as

  &amp;lt;hash of ietf-822&amp;gt;._mayresign.ietf.org TXT "v=MR1; d=ietf.org"

That says the ietf-822 at ietf.org list is signed with d=ietf.org.  If a domain contains only mailing lists, you can use a wildcard

  *._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"

A submission server can then derive that one of its users is a subscriber of a list declared that way.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>7a5d21b71647063507842fe2d265e915d488faec</sha1>
  </revision>
  <revision>
    <id>1599</id>
    <parentid>1598</parentid>
    <timestamp>2019-08-27T14:43:25Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>/* Triple Opt-In */ is-&gt;would be</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="11398" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the precondition for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby betraying any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

There is an EU regulation, [[wp:eIDAS]], a standard developed for transactions in the EU single market.  It can be considered a sort of S/MIME extension; that is, it features centralized key management -the main difference w.r.t. the PGP suite.  That way, data subject's consent could by acquired by means of a ''trust service provider'' according to regulation.  A statement like this would be consistent with law-regulated privacy protection.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' would be a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

===Criticism===
A reason to avoid the term ''triple opt-in'' altogether is that it is being used with a different (marketing) meaning, see e.g. [http://www.mmaglobal.com/wiki/triple-opt here].

An additional weakness is that a user's mail server can just be grateful for the information supplied, and decline to send a proper acknowledge to the wannabe sender.  Since the sender is doing this in order to have such legal proof of its conduct, lazy mailbox provider behavior can hamper a naive implementation.

Let me name this [[Water tight opt-in]], following David Hofstee.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

=== Update 2018 ===
The new [http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679 REGULATION 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL] of 27 April 2016, article 68, states (my enhancing):
&lt;blockquote&gt;
To further strengthen the control over his or her own data, where the processing of personal data is carried out by automated means, the data subject should also be allowed to receive personal data concerning him or her which he or she has provided to a controller in a structured, commonly used, machine-readable and interoperable format, and to transmit it to another controller. '''Data controllers should be encouraged to develop interoperable formats that enable data portability.''' That right should apply where the data subject provided the personal data on the basis of his or her consent or the processing is necessary for the performance of a contract. It should not apply where processing is based on a legal ground other than consent or contract. By its very nature, that right should not be exercised against controllers processing personal data in the exercise of their public duties. It should therefore not apply where the processing of the personal data is necessary for compliance with a legal obligation to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of an official authority vested in the controller. The data subject's right to transmit or receive personal data concerning him or her should not create an obligation for the controllers to adopt or maintain processing systems which are technically compatible. Where, in a certain set of personal data, more than one data subject is concerned, the right to receive the personal data should be without prejudice to the rights and freedoms of other data subjects in accordance with this Regulation. Furthermore, that right should not prejudice the right of the data subject to obtain the erasure of personal data and the limitations of that right as set out in this Regulation and should, in particular, not imply the erasure of personal data concerning the data subject which have been provided by him or her for the performance of a contract to the extent that and for as long as the personal data are necessary for the performance of that contract. Where technically feasible, the data subject should have the right to have the personal data transmitted directly from one controller to another.
&lt;/blockquote&gt;

Besides all the limitations intended to safeguard data controllers, it clearly calls for such a standard.

== DNS declaration of mailing list ==
Yet another idea is to use DNS RRs to declare that a given email address is a mailing list (suggested by John Levine [http://www.ietf.org/mail-archive/web/ietf-822/current/msg06714.html here]).  It is exemplified as

  &amp;lt;hash of ietf-822&amp;gt;._mayresign.ietf.org TXT "v=MR1; d=ietf.org"

That says the ietf-822 at ietf.org list is signed with d=ietf.org.  If a domain contains only mailing lists, you can use a wildcard

  *._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"

A submission server can then derive that one of its users is a subscriber of a list declared that way.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>270a0eabd8d5e966aeb5eb9d881736c7081d8d13</sha1>
  </revision>
  <revision>
    <id>1600</id>
    <parentid>1599</parentid>
    <timestamp>2019-08-27T17:39:03Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Criticism */ prepend paragraph on distrust between users an mailbox providers</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="12490" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the precondition for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby betraying any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

There is an EU regulation, [[wp:eIDAS]], a standard developed for transactions in the EU single market.  It can be considered a sort of S/MIME extension; that is, it features centralized key management -the main difference w.r.t. the PGP suite.  That way, data subject's consent could by acquired by means of a ''trust service provider'' according to regulation.  A statement like this would be consistent with law-regulated privacy protection.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' would be a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

===Criticism===
The main reason why that kind of authentication won't come is that it implies a trust between users and their mailbox providers.  Such trust may seem to be taken for granted, considering, for example, that forgotten passwords are reset through email.  A person's email address has become an identity token.  Yet, there are users who hardly cope with having to entrust their communications to a third party suspected of sniffing it, profiling and reselling private data, and worse.  Things would be different if the mailbox provider were the server of a household, of a company, a club, or similar associations.  In fact, the 'domain-part' of an address used to characterize people.  Nowadays, everyone has 'gmail'.  There are two reasons for this state of affairs.  One is that running a mail server is not so straightforward.  The other one is that server connections cost much more than residential ones.  Having to put the server at the mercy of an external admin doesn't seem to be much different than letting the external admin manage the mail directly, as far as privacy is concerned.

A reason to avoid the term ''triple opt-in'' altogether is that it is being used with a different (marketing) meaning, see e.g. [http://www.mmaglobal.com/wiki/triple-opt here].

An additional weakness is that a user's mail server can just be grateful for the information supplied, and decline to send a proper acknowledge to the wannabe sender.  Since the sender is doing this in order to have such legal proof of its conduct, lazy mailbox provider behavior can hamper a naive implementation.

Let me name this [[Water tight opt-in]], following David Hofstee.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

=== Update 2018 ===
The new [http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679 REGULATION 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL] of 27 April 2016, article 68, states (my enhancing):
&lt;blockquote&gt;
To further strengthen the control over his or her own data, where the processing of personal data is carried out by automated means, the data subject should also be allowed to receive personal data concerning him or her which he or she has provided to a controller in a structured, commonly used, machine-readable and interoperable format, and to transmit it to another controller. '''Data controllers should be encouraged to develop interoperable formats that enable data portability.''' That right should apply where the data subject provided the personal data on the basis of his or her consent or the processing is necessary for the performance of a contract. It should not apply where processing is based on a legal ground other than consent or contract. By its very nature, that right should not be exercised against controllers processing personal data in the exercise of their public duties. It should therefore not apply where the processing of the personal data is necessary for compliance with a legal obligation to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of an official authority vested in the controller. The data subject's right to transmit or receive personal data concerning him or her should not create an obligation for the controllers to adopt or maintain processing systems which are technically compatible. Where, in a certain set of personal data, more than one data subject is concerned, the right to receive the personal data should be without prejudice to the rights and freedoms of other data subjects in accordance with this Regulation. Furthermore, that right should not prejudice the right of the data subject to obtain the erasure of personal data and the limitations of that right as set out in this Regulation and should, in particular, not imply the erasure of personal data concerning the data subject which have been provided by him or her for the performance of a contract to the extent that and for as long as the personal data are necessary for the performance of that contract. Where technically feasible, the data subject should have the right to have the personal data transmitted directly from one controller to another.
&lt;/blockquote&gt;

Besides all the limitations intended to safeguard data controllers, it clearly calls for such a standard.

== DNS declaration of mailing list ==
Yet another idea is to use DNS RRs to declare that a given email address is a mailing list (suggested by John Levine [http://www.ietf.org/mail-archive/web/ietf-822/current/msg06714.html here]).  It is exemplified as

  &amp;lt;hash of ietf-822&amp;gt;._mayresign.ietf.org TXT "v=MR1; d=ietf.org"

That says the ietf-822 at ietf.org list is signed with d=ietf.org.  If a domain contains only mailing lists, you can use a wildcard

  *._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"

A submission server can then derive that one of its users is a subscriber of a list declared that way.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;</text>
    <sha1>4401f1f76697f0877614fc5ea72c2916035d747d</sha1>
  </revision>
  <revision>
    <id>1606</id>
    <parentid>1600</parentid>
    <timestamp>2023-03-08T16:20:41Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Papers */ New section for citations</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="12795" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the precondition for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby betraying any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

There is an EU regulation, [[wp:eIDAS]], a standard developed for transactions in the EU single market.  It can be considered a sort of S/MIME extension; that is, it features centralized key management -the main difference w.r.t. the PGP suite.  That way, data subject's consent could by acquired by means of a ''trust service provider'' according to regulation.  A statement like this would be consistent with law-regulated privacy protection.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' would be a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

===Criticism===
The main reason why that kind of authentication won't come is that it implies a trust between users and their mailbox providers.  Such trust may seem to be taken for granted, considering, for example, that forgotten passwords are reset through email.  A person's email address has become an identity token.  Yet, there are users who hardly cope with having to entrust their communications to a third party suspected of sniffing it, profiling and reselling private data, and worse.  Things would be different if the mailbox provider were the server of a household, of a company, a club, or similar associations.  In fact, the 'domain-part' of an address used to characterize people.  Nowadays, everyone has 'gmail'.  There are two reasons for this state of affairs.  One is that running a mail server is not so straightforward.  The other one is that server connections cost much more than residential ones.  Having to put the server at the mercy of an external admin doesn't seem to be much different than letting the external admin manage the mail directly, as far as privacy is concerned.

A reason to avoid the term ''triple opt-in'' altogether is that it is being used with a different (marketing) meaning, see e.g. [http://www.mmaglobal.com/wiki/triple-opt here].

An additional weakness is that a user's mail server can just be grateful for the information supplied, and decline to send a proper acknowledge to the wannabe sender.  Since the sender is doing this in order to have such legal proof of its conduct, lazy mailbox provider behavior can hamper a naive implementation.

Let me name this [[Water tight opt-in]], following David Hofstee.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

=== Update 2018 ===
The new [http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679 REGULATION 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL] of 27 April 2016, article 68, states (my enhancing):
&lt;blockquote&gt;
To further strengthen the control over his or her own data, where the processing of personal data is carried out by automated means, the data subject should also be allowed to receive personal data concerning him or her which he or she has provided to a controller in a structured, commonly used, machine-readable and interoperable format, and to transmit it to another controller. '''Data controllers should be encouraged to develop interoperable formats that enable data portability.''' That right should apply where the data subject provided the personal data on the basis of his or her consent or the processing is necessary for the performance of a contract. It should not apply where processing is based on a legal ground other than consent or contract. By its very nature, that right should not be exercised against controllers processing personal data in the exercise of their public duties. It should therefore not apply where the processing of the personal data is necessary for compliance with a legal obligation to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of an official authority vested in the controller. The data subject's right to transmit or receive personal data concerning him or her should not create an obligation for the controllers to adopt or maintain processing systems which are technically compatible. Where, in a certain set of personal data, more than one data subject is concerned, the right to receive the personal data should be without prejudice to the rights and freedoms of other data subjects in accordance with this Regulation. Furthermore, that right should not prejudice the right of the data subject to obtain the erasure of personal data and the limitations of that right as set out in this Regulation and should, in particular, not imply the erasure of personal data concerning the data subject which have been provided by him or her for the performance of a contract to the extent that and for as long as the personal data are necessary for the performance of that contract. Where technically feasible, the data subject should have the right to have the personal data transmitted directly from one controller to another.
&lt;/blockquote&gt;

Besides all the limitations intended to safeguard data controllers, it clearly calls for such a standard.

== DNS declaration of mailing list ==
Yet another idea is to use DNS RRs to declare that a given email address is a mailing list (suggested by John Levine [http://www.ietf.org/mail-archive/web/ietf-822/current/msg06714.html here]).  It is exemplified as

  &amp;lt;hash of ietf-822&amp;gt;._mayresign.ietf.org TXT "v=MR1; d=ietf.org"

That says the ietf-822 at ietf.org list is signed with d=ietf.org.  If a domain contains only mailing lists, you can use a wildcard

  *._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"

A submission server can then derive that one of its users is a subscriber of a list declared that way.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;

== Papers ==
A nice taxonomy of email forwarding methods and weaknesses thereof, as of 2023, is given by [https://arxiv.org/search/cs?searchtype=author&amp;query=Liu%2C+E Enze Liu] et al. [https://arxiv.org/abs/2302.07287 Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy].</text>
    <sha1>c713d7c9d1c9c89b7c98710f34c0d35f4036276a</sha1>
  </revision>
  <revision>
    <id>1607</id>
    <parentid>1606</parentid>
    <timestamp>2023-07-06T06:11:31Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Update 2023 */   New subsection</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="13052" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship.  Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off.  A ''responsible marketing'' is the precondition for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby betraying any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

There is an EU regulation, [[wp:eIDAS]], a standard developed for transactions in the EU single market.  It can be considered a sort of S/MIME extension; that is, it features centralized key management -the main difference w.r.t. the PGP suite.  That way, data subject's consent could by acquired by means of a ''trust service provider'' according to regulation.  A statement like this would be consistent with law-regulated privacy protection.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' would be a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

===Criticism===
The main reason why that kind of authentication won't come is that it implies a trust between users and their mailbox providers.  Such trust may seem to be taken for granted, considering, for example, that forgotten passwords are reset through email.  A person's email address has become an identity token.  Yet, there are users who hardly cope with having to entrust their communications to a third party suspected of sniffing it, profiling and reselling private data, and worse.  Things would be different if the mailbox provider were the server of a household, of a company, a club, or similar associations.  In fact, the 'domain-part' of an address used to characterize people.  Nowadays, everyone has 'gmail'.  There are two reasons for this state of affairs.  One is that running a mail server is not so straightforward.  The other one is that server connections cost much more than residential ones.  Having to put the server at the mercy of an external admin doesn't seem to be much different than letting the external admin manage the mail directly, as far as privacy is concerned.

A reason to avoid the term ''triple opt-in'' altogether is that it is being used with a different (marketing) meaning, see e.g. [http://www.mmaglobal.com/wiki/triple-opt here].

An additional weakness is that a user's mail server can just be grateful for the information supplied, and decline to send a proper acknowledge to the wannabe sender.  Since the sender is doing this in order to have such legal proof of its conduct, lazy mailbox provider behavior can hamper a naive implementation.

Let me name this [[Water tight opt-in]], following David Hofstee.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

=== Update 2018 ===
The new [http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679 REGULATION 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL] of 27 April 2016, article 68, states (my enhancing):
&lt;blockquote&gt;
To further strengthen the control over his or her own data, where the processing of personal data is carried out by automated means, the data subject should also be allowed to receive personal data concerning him or her which he or she has provided to a controller in a structured, commonly used, machine-readable and interoperable format, and to transmit it to another controller. '''Data controllers should be encouraged to develop interoperable formats that enable data portability.''' That right should apply where the data subject provided the personal data on the basis of his or her consent or the processing is necessary for the performance of a contract. It should not apply where processing is based on a legal ground other than consent or contract. By its very nature, that right should not be exercised against controllers processing personal data in the exercise of their public duties. It should therefore not apply where the processing of the personal data is necessary for compliance with a legal obligation to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of an official authority vested in the controller. The data subject's right to transmit or receive personal data concerning him or her should not create an obligation for the controllers to adopt or maintain processing systems which are technically compatible. Where, in a certain set of personal data, more than one data subject is concerned, the right to receive the personal data should be without prejudice to the rights and freedoms of other data subjects in accordance with this Regulation. Furthermore, that right should not prejudice the right of the data subject to obtain the erasure of personal data and the limitations of that right as set out in this Regulation and should, in particular, not imply the erasure of personal data concerning the data subject which have been provided by him or her for the performance of a contract to the extent that and for as long as the personal data are necessary for the performance of that contract. Where technically feasible, the data subject should have the right to have the personal data transmitted directly from one controller to another.
&lt;/blockquote&gt;

Besides all the limitations intended to safeguard data controllers, it clearly calls for such a standard.

=== Update 2023 ===
After more thinking, catching both user confirmation to the mailing list and user's mailbox provider consent to pass the mail flow in a single gesture is too much.  The protocol shall provided for both points to be done asynchronously.

== DNS declaration of mailing list ==
Yet another idea is to use DNS RRs to declare that a given email address is a mailing list (suggested by John Levine [http://www.ietf.org/mail-archive/web/ietf-822/current/msg06714.html here]).  It is exemplified as

  &amp;lt;hash of ietf-822&amp;gt;._mayresign.ietf.org TXT "v=MR1; d=ietf.org"

That says the ietf-822 at ietf.org list is signed with d=ietf.org.  If a domain contains only mailing lists, you can use a wildcard

  *._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"

A submission server can then derive that one of its users is a subscriber of a list declared that way.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;

== Papers ==
A nice taxonomy of email forwarding methods and weaknesses thereof, as of 2023, is given by [https://arxiv.org/search/cs?searchtype=author&amp;query=Liu%2C+E Enze Liu] et al. [https://arxiv.org/abs/2302.07287 Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy].</text>
    <sha1>d89425733a093a69831a9885dad86d5615c0c598</sha1>
  </revision>
  <revision>
    <id>1608</id>
    <parentid>1607</parentid>
    <timestamp>2023-10-12T16:13:26Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Rationale */ wording</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="13082" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship with customers.  Production and distribution of goods and services should rather be a symbiotic relationship.  The minority working against that ought to be pushed off.  A ''responsible marketing'' is the precondition for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.  In most countries, this should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby betraying any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

There is an EU regulation, [[wp:eIDAS]], a standard developed for transactions in the EU single market.  It can be considered a sort of S/MIME extension; that is, it features centralized key management -the main difference w.r.t. the PGP suite.  That way, data subject's consent could by acquired by means of a ''trust service provider'' according to regulation.  A statement like this would be consistent with law-regulated privacy protection.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' would be a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

===Criticism===
The main reason why that kind of authentication won't come is that it implies a trust between users and their mailbox providers.  Such trust may seem to be taken for granted, considering, for example, that forgotten passwords are reset through email.  A person's email address has become an identity token.  Yet, there are users who hardly cope with having to entrust their communications to a third party suspected of sniffing it, profiling and reselling private data, and worse.  Things would be different if the mailbox provider were the server of a household, of a company, a club, or similar associations.  In fact, the 'domain-part' of an address used to characterize people.  Nowadays, everyone has 'gmail'.  There are two reasons for this state of affairs.  One is that running a mail server is not so straightforward.  The other one is that server connections cost much more than residential ones.  Having to put the server at the mercy of an external admin doesn't seem to be much different than letting the external admin manage the mail directly, as far as privacy is concerned.

A reason to avoid the term ''triple opt-in'' altogether is that it is being used with a different (marketing) meaning, see e.g. [http://www.mmaglobal.com/wiki/triple-opt here].

An additional weakness is that a user's mail server can just be grateful for the information supplied, and decline to send a proper acknowledge to the wannabe sender.  Since the sender is doing this in order to have such legal proof of its conduct, lazy mailbox provider behavior can hamper a naive implementation.

Let me name this [[Water tight opt-in]], following David Hofstee.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

=== Update 2018 ===
The new [http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679 REGULATION 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL] of 27 April 2016, article 68, states (my enhancing):
&lt;blockquote&gt;
To further strengthen the control over his or her own data, where the processing of personal data is carried out by automated means, the data subject should also be allowed to receive personal data concerning him or her which he or she has provided to a controller in a structured, commonly used, machine-readable and interoperable format, and to transmit it to another controller. '''Data controllers should be encouraged to develop interoperable formats that enable data portability.''' That right should apply where the data subject provided the personal data on the basis of his or her consent or the processing is necessary for the performance of a contract. It should not apply where processing is based on a legal ground other than consent or contract. By its very nature, that right should not be exercised against controllers processing personal data in the exercise of their public duties. It should therefore not apply where the processing of the personal data is necessary for compliance with a legal obligation to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of an official authority vested in the controller. The data subject's right to transmit or receive personal data concerning him or her should not create an obligation for the controllers to adopt or maintain processing systems which are technically compatible. Where, in a certain set of personal data, more than one data subject is concerned, the right to receive the personal data should be without prejudice to the rights and freedoms of other data subjects in accordance with this Regulation. Furthermore, that right should not prejudice the right of the data subject to obtain the erasure of personal data and the limitations of that right as set out in this Regulation and should, in particular, not imply the erasure of personal data concerning the data subject which have been provided by him or her for the performance of a contract to the extent that and for as long as the personal data are necessary for the performance of that contract. Where technically feasible, the data subject should have the right to have the personal data transmitted directly from one controller to another.
&lt;/blockquote&gt;

Besides all the limitations intended to safeguard data controllers, it clearly calls for such a standard.

=== Update 2023 ===
After more thinking, catching both user confirmation to the mailing list and user's mailbox provider consent to pass the mail flow in a single gesture is too much.  The protocol shall provided for both points to be done asynchronously.

== DNS declaration of mailing list ==
Yet another idea is to use DNS RRs to declare that a given email address is a mailing list (suggested by John Levine [http://www.ietf.org/mail-archive/web/ietf-822/current/msg06714.html here]).  It is exemplified as

  &amp;lt;hash of ietf-822&amp;gt;._mayresign.ietf.org TXT "v=MR1; d=ietf.org"

That says the ietf-822 at ietf.org list is signed with d=ietf.org.  If a domain contains only mailing lists, you can use a wildcard

  *._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"

A submission server can then derive that one of its users is a subscriber of a list declared that way.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;

== Papers ==
A nice taxonomy of email forwarding methods and weaknesses thereof, as of 2023, is given by [https://arxiv.org/search/cs?searchtype=author&amp;query=Liu%2C+E Enze Liu] et al. [https://arxiv.org/abs/2302.07287 Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy].</text>
    <sha1>346f2ee769977993c0c021cef82588419feb45bc</sha1>
  </revision>
  <revision>
    <id>1609</id>
    <parentid>1608</parentid>
    <timestamp>2023-10-12T17:08:25Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* The problem */ separate the legal conundrum into its own section, consider email authentication and link my draft</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="14059" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship with customers.  Production and distribution of goods and services should rather be a symbiotic relationship.  The minority working against that ought to be pushed off.  A ''responsible marketing'' is the precondition for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk messages that characterizes email: the destination addresses can be held on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.

[[wp:Email Authentication]] is typically baffled by indirect mail flows.  [[wp:Sender Policy Framework|SPF]] breaks forwarding by design.  [[wp:DomainKeys Identified Mail|DKIM]] should withstand forwarding.  However, occasional alterations or deliberate, legitimate additions break signatures as well.  This state of affairs hinders the possibility to use domain authentication as a means to control email abuse.  If it were not for forwarding, it would be possible to build reliable reputation systems.  That way, authors would have to be responsible for what they send.

A possible mitigation is to pair the email addresses stored on a list exploder with tags stored at the corresponding receivers, so that the latter can categorize indirect mail flows and allow their users to control them.  This idea is drafted in [https://datatracker.ietf.org/doc/html/draft-vesely-fix-forwarding Agreements To Fix Forwarding]

== Legal conundrum ==
In most countries, storing personal data on a server should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby betraying any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

There is an EU regulation, [[wp:eIDAS]], a standard developed for transactions in the EU single market.  It can be considered a sort of S/MIME extension; that is, it features centralized key management -the main difference w.r.t. the PGP suite.  That way, data subject's consent could by acquired by means of a ''trust service provider'' according to regulation.  A statement like this would be consistent with law-regulated privacy protection.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' would be a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

===Criticism===
The main reason why that kind of authentication won't come is that it implies a trust between users and their mailbox providers.  Such trust may seem to be taken for granted, considering, for example, that forgotten passwords are reset through email.  A person's email address has become an identity token.  Yet, there are users who hardly cope with having to entrust their communications to a third party suspected of sniffing it, profiling and reselling private data, and worse.  Things would be different if the mailbox provider were the server of a household, of a company, a club, or similar associations.  In fact, the 'domain-part' of an address used to characterize people.  Nowadays, everyone has 'gmail'.  There are two reasons for this state of affairs.  One is that running a mail server is not so straightforward.  The other one is that server connections cost much more than residential ones.  Having to put the server at the mercy of an external admin doesn't seem to be much different than letting the external admin manage the mail directly, as far as privacy is concerned.

A reason to avoid the term ''triple opt-in'' altogether is that it is being used with a different (marketing) meaning, see e.g. [http://www.mmaglobal.com/wiki/triple-opt here].

An additional weakness is that a user's mail server can just be grateful for the information supplied, and decline to send a proper acknowledge to the wannabe sender.  Since the sender is doing this in order to have such legal proof of its conduct, lazy mailbox provider behavior can hamper a naive implementation.

Let me name this [[Water tight opt-in]], following David Hofstee.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

=== Update 2018 ===
The new [http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679 REGULATION 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL] of 27 April 2016, article 68, states (my enhancing):
&lt;blockquote&gt;
To further strengthen the control over his or her own data, where the processing of personal data is carried out by automated means, the data subject should also be allowed to receive personal data concerning him or her which he or she has provided to a controller in a structured, commonly used, machine-readable and interoperable format, and to transmit it to another controller. '''Data controllers should be encouraged to develop interoperable formats that enable data portability.''' That right should apply where the data subject provided the personal data on the basis of his or her consent or the processing is necessary for the performance of a contract. It should not apply where processing is based on a legal ground other than consent or contract. By its very nature, that right should not be exercised against controllers processing personal data in the exercise of their public duties. It should therefore not apply where the processing of the personal data is necessary for compliance with a legal obligation to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of an official authority vested in the controller. The data subject's right to transmit or receive personal data concerning him or her should not create an obligation for the controllers to adopt or maintain processing systems which are technically compatible. Where, in a certain set of personal data, more than one data subject is concerned, the right to receive the personal data should be without prejudice to the rights and freedoms of other data subjects in accordance with this Regulation. Furthermore, that right should not prejudice the right of the data subject to obtain the erasure of personal data and the limitations of that right as set out in this Regulation and should, in particular, not imply the erasure of personal data concerning the data subject which have been provided by him or her for the performance of a contract to the extent that and for as long as the personal data are necessary for the performance of that contract. Where technically feasible, the data subject should have the right to have the personal data transmitted directly from one controller to another.
&lt;/blockquote&gt;

Besides all the limitations intended to safeguard data controllers, it clearly calls for such a standard.

=== Update 2023 ===
After more thinking, catching both user confirmation to the mailing list and user's mailbox provider consent to pass the mail flow in a single gesture is too much.  The protocol shall provided for both points to be done asynchronously.

== DNS declaration of mailing list ==
Yet another idea is to use DNS RRs to declare that a given email address is a mailing list (suggested by John Levine [http://www.ietf.org/mail-archive/web/ietf-822/current/msg06714.html here]).  It is exemplified as

  &amp;lt;hash of ietf-822&amp;gt;._mayresign.ietf.org TXT "v=MR1; d=ietf.org"

That says the ietf-822 at ietf.org list is signed with d=ietf.org.  If a domain contains only mailing lists, you can use a wildcard

  *._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"

A submission server can then derive that one of its users is a subscriber of a list declared that way.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;

== Papers ==
A nice taxonomy of email forwarding methods and weaknesses thereof, as of 2023, is given by [https://arxiv.org/search/cs?searchtype=author&amp;query=Liu%2C+E Enze Liu] et al. [https://arxiv.org/abs/2302.07287 Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy].</text>
    <sha1>68eeae01291b919f2ef805aacda1c1ddd0b58d7f</sha1>
  </revision>
</page>
<page arvcontinue="20101017125844|1559">
  <title>solution proposed</title>
  <ns>0</ns>
  <id>16</id>
  <revision>
    <id>1565</id>
    <parentid>1475</parentid>
    <timestamp>2011-09-17T15:54:25Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Summary */ mention other possibilities beyond SMTP AUTH</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6108" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Summary ==
By negotiating a ''forwarding agreement'', a sender obtains an SMTP AUTH id/password pair that it can use to relay messages destined to a given user on the relevant server. The receiver maintains a list of agreements, matching one-to-one with the corresponding elements at the senders' alias expansion lists.

There are other possibilities, beyond SMTP AUTH.  For example,
* the server might use an opaque email address, e.g. ''user-12345@domain'', that is given to that sender only, or
* the sender may sign mail using DKIM, in case the authorization is intended to cover ''any'' message that the signing domain may send.

Agreements are classified into different categories, e.g., static ''.forward'' files, newsletters, mailing lists. An agreement is required for each target user and for each subscription. For example, if sender A runs one mailing list and two newsletters, and two users at receiver B subscribe to all of them, then B will store six agreements for A, just like A has six recipes for B.

Agreements may be obtained in a fully automated fashion. However, it is also possible to require human inspection as desired. Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops.

This model of forwarding can be triggered by means of a local tweak and a light SMTP extension. The tweak on the sender side consists of a local encoding of the envelope sender that lets the sending software know that a message is being forwarded, and provides a parameter for either negotiating an agreement or using an existing one. This has to be enabled by setting the ''-f'' command switch accordingly, for each recipe. The tweaked envelope sender only lives locally, i.e. on the relevant host or ADMD. The extension on the receiver side is an EHLO keyword to let the sending software know that the specific MX being contacted is also willing to use forwarding agreements.

The negotiation required to establish a forwarding agreement can be quite complicate, especially for the first agreement between two organizations. It provides for a three-way handshake during which the servers exchange the relevant credentials and URLs required to re-negotiate the agreement. By contrast, normal use of an existing agreement is very cheap: the sender finds the id/password pair in a local database, and the remote MX authenticates it normally.

== Pluses ==
This solution attempts to impose some order in the ''real and extensive diversity of email transfer scenarios'', as Dave Crocker describes it[http://www.irtf.org/pipermail/asrg/2008-December/004192.html].

=== Anti-Spam effects ===
The major effect of this solution against spam consists in enabling [[boundary filter]]s. Some of those filters, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

A second effect is to improve legal stances. The usual definition of spam, "unsolicited bulk email", does not distinguish spammers who use false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

=== Unified unsubscribe ===
The data gathered with each agreement can be easily made available to UIs aiming at enumerating users subscriptions, possibly recursively. Agreements can be presented in historical order and/or by category, allowing users to change preferences and unsubscribe.

Rather than hitting "report spam" buttons on a per-message basis, users could target the whole series of messages that arrived under a given agreement. Such semantic shift may help to disambiguate an attempt to report that a single message is spam, not the newsletter it belongs to.

== Minuses ==
Managing agreements is an additional burden. Are we ready?

=== False security ===
Automatically stipulated agreements are not bullet proof. Questionable senders may sneak in and send messages that formally look like having passed through SMTP AUTH. Although it may actually be easier for a server to monitor messages grouping them by ''forwarder-id'' rather than (or in addition to) IP address, downstream software may erroneously assume that ''Received'' or ''Authentication-Results'' headers exhibiting smpt.auth data imply a well identified sender.

=== Easy attack path ===
Since receiving hosts promise to skip some boundary checks for forwarded messages, spammers may just use a zombie and an easily obtained TLS certificate to stipulate forwarding agreements. Then they can send spam more easily to those hosts. If it is too easy to obtain an agreement, this solution won't work. However, it is possible to invest more time and precautions during the negotiation handshake than it would for single messages: that's the challenge hereby proposed.

== History ==
The ''ff'' idea arose in a discussion originated on the spf-discuss list in January 2008[http://www.listbox.com/member/archive/735/2008/01/sort/thread_rev/page/1/entry/11:265/20080131110008:4871D6CE-D015-11DC-8216-54C5B46F41FF/]. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG[http://www.nabble.com/Yet-another-attempt-to-fix-forwarding-td15177052.html] and Courier-users[http://www.mail-archive.com/courier-users@lists.sourceforge.net/msg30908.html] mailing lists, where it just originated more or less (respectively) responses on SPF/SRS topics only. The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born.</text>
    <sha1>404d62ea47671ae652536b2df7f9c91939cdb64b</sha1>
  </revision>
  <revision>
    <id>1574</id>
    <parentid>1565</parentid>
    <timestamp>2012-01-25T13:01:32Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Summary */ converted in Requirements + Verification</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7145" xml:space="preserve">The '''solution proposed''' by this site aims at fixing email [[forwarding]] by introducing [[forwarding agreement]]s as a counterpart of [[forwarding recipe]]s.

== Requirements ==
Agreements are classified into different categories, e.g., static ''dot-forward'' files, newsletters, mailing lists. An agreement is required for each target user and for each subscription. For example, if sender A runs one mailing list and two newsletters, and two users at receiver B subscribe to all of them, then B will store six agreements for A, just like A has six recipes for B.

Agreements may be obtained in a fully automated fashion.  That means that a compliant sender can find out whether the target MTA supports this solution and automatically convert a to it in case.  However, it must also be possible to require human inspection as desired.

Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops.

This model of forwarding can be triggered by means of a local tweak and a light SMTP extension. The tweak on the sender side consists of a local encoding of the envelope sender that lets the sending software know that a message is being forwarded, and provides a parameter for either negotiating an agreement or using an existing one. This has to be enabled by setting the ''-f'' command switch accordingly, for each recipe. The tweaked envelope sender only lives locally, i.e. on the relevant host or ADMD. The extension on the receiver side is an EHLO keyword to let the sending software know that the specific MX being contacted is also willing to use forwarding agreements.

The negotiation required to establish a forwarding agreement could be quite demanding, especially for the first agreement between two organizations. &lt;!-- It provides for a three-way handshake during which the servers exchange the relevant credentials and URLs required to re-negotiate the agreement. By contrast, normal use of an existing agreement is very cheap: the sender finds the id/password pair in a local database, and the remote MX authenticates it normally.--&gt;

== Verification ==
Here are two methods to verify that a message is being forwarded legitimately by a compliant sender.

=== DKIM / SPF authentication plus unique addresses ===
* The server generates a unique opaque email address, e.g. ''user-12345@domain'', that is given to that sender only, and
* the sender authenticates with DKIM and/or SPF, referring which agreement it is using either in the envelope (as a new SMTP parameter) or in the message (in a header field such as List-Id).

Using Base32 encoding for the variant part allows for enough addresses to connect each pair of individuals in the world, since the local-part can be up to 64 chars long.

The sender has to be trusted for referencing the correct agreement.

=== SMPT AUTH ===
By negotiating a ''forwarding agreement'', a sender obtains an SMTP AUTH id/password pair that it can use to relay messages destined to a given user on the relevant server. The receiver maintains a list of agreements, matching one-to-one with the corresponding elements at the senders' alias expansion lists.

An MTA has to be able to not grant relaying rights to this kind of authenticated senders, while still using authentication (in Submission servers) as usual for local users.

SMTP AUTH allows senders to change hat for each message being sent during a given session.  This has to be implemented by the receiving MTA, so that the same entity can act upon different agreements at the same server.  Again, the sender has to be trusted for this.

== Pluses ==
This solution attempts to impose some order in the ''real and extensive diversity of email transfer scenarios'', as Dave Crocker describes it[http://www.irtf.org/pipermail/asrg/2008-December/004192.html].

=== Anti-Spam effects ===
The major effect of this solution against spam consists in enabling [[boundary filter]]s. Some of those filters, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their ''real'' domain names would confront them with their responsibilities.

A second effect is to improve legal stances. The usual definition of spam, "unsolicited bulk email", does not distinguish spammers who use false identities and zombies, thereby breaking ''criminal laws'', from those who don't respect opt-in rules or similar ''civil law'' issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

=== Unified unsubscribe ===
The data gathered with each agreement can be easily made available to UIs aiming at enumerating users subscriptions, possibly recursively. Agreements can be presented in historical order and/or by category, allowing users to change preferences and unsubscribe.

Rather than hitting "report spam" buttons on a per-message basis, users could target the whole series of messages that arrived under a given agreement. Such semantic shift may help to disambiguate an attempt to report that a single message is spam, not the newsletter it belongs to.

== Minuses ==
Managing agreements is an additional burden. Are we ready?

=== False security ===
Automatically stipulated agreements are not bullet proof. Questionable senders may sneak in and send messages that formally look like having passed through SMTP AUTH. Although it may actually be easier for a server to monitor messages grouping them by ''forwarder-id'' rather than (or in addition to) IP address, downstream software may erroneously assume that ''Received'' or ''Authentication-Results'' headers exhibiting smpt.auth data imply a well identified sender.

=== Easy attack path ===
Since receiving hosts promise to skip some boundary checks for forwarded messages, spammers may just use a zombie and an easily obtained TLS certificate to stipulate forwarding agreements. Then they can send spam more easily to those hosts. If it is too easy to obtain an agreement, this solution won't work. However, it is possible to invest more time and precautions during the negotiation handshake than it would for single messages: that's the challenge hereby proposed.

== History ==
The ''ff'' idea arose in a discussion originated on the spf-discuss list in January 2008[http://www.listbox.com/member/archive/735/2008/01/sort/thread_rev/page/1/entry/11:265/20080131110008:4871D6CE-D015-11DC-8216-54C5B46F41FF/]. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG[http://www.nabble.com/Yet-another-attempt-to-fix-forwarding-td15177052.html] and Courier-users[http://www.mail-archive.com/courier-users@lists.sourceforge.net/msg30908.html] mailing lists, where it just originated more or less (respectively) responses on SPF/SRS topics only. The idea itself is not ''very'' complicated, but it has to be described gradually. Thus this site born.</text>
    <sha1>0a5ffffb6ddc1d1467ebdafeae46835de2697c95</sha1>
  </revision>
</page>
<page arvcontinue="20101017125844|1559">
  <title>File:mailflows-0.png</title>
  <ns>6</ns>
  <id>37</id>
  <revision>
    <id>1576</id>
    <timestamp>2013-02-13T09:44:01Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>The mail flows as originally designed by Patrik Fältström.</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="60" xml:space="preserve">The mail flows as originally designed by Patrik Fältström.</text>
    <sha1>73dc955ce3b27ccc46fcc3f7b983122b0ab0bca8</sha1>
  </revision>
</page>
<page arvcontinue="20101017125844|1559">
  <title>File:mailflows-1.png</title>
  <ns>6</ns>
  <id>38</id>
  <revision>
    <id>1577</id>
    <timestamp>2013-02-13T09:45:57Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>The mail flows as published by openspf.org</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="42" xml:space="preserve">The mail flows as published by openspf.org</text>
    <sha1>8ca9e2d6edf52364a13559a5d58db0f1e2584cf7</sha1>
  </revision>
</page>
<page arvcontinue="20101017125844|1559">
  <title>mail flows</title>
  <ns>0</ns>
  <id>39</id>
  <revision>
    <id>1578</id>
    <timestamp>2013-02-13T10:37:02Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Create a page with links to the original pdf (cannot upload to Wikimedia because of unknown copyright)</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="389" xml:space="preserve">Here are the '''mail flows''' pictures.  Links to pdf files are provided.

==Original==
[[File:mailflows-0.png|frame|none|The original design by Patrik Fältström. &lt;span style="float: right;"&gt;[{{SERVER}}/mailflows-0.pdf pdf]&lt;/span&gt;]]


==Revised==
[[File:mailflows-1.png|frame|none|The revised version, unknown author. &lt;span style="float: right;"&gt;[{{SERVER}}/mailflows-1.pdf pdf]&lt;/span&gt;]]</text>
    <sha1>c88b5aabfa1b53a624e1cc79b3f290e187151167</sha1>
  </revision>
  <revision>
    <id>1579</id>
    <parentid>1578</parentid>
    <timestamp>2013-02-13T13:22:46Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>link to wikipedia</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="453" xml:space="preserve">Here are the '''mail flows''' pictures.  Links to pdf files are provided.

==Original==
[[File:mailflows-0.png|frame|none|The original design by Patrik Fältström. &lt;span style="float: right;"&gt;[{{SERVER}}/mailflows-0.pdf pdf]&lt;/span&gt;]]


==Revised==
[[File:mailflows-1.png|frame|none|The revised version, unknown author. &lt;span style="float: right;"&gt;[{{SERVER}}/mailflows-1.pdf pdf]&lt;/span&gt;]]

A derivative is used to illustrate [[wp:Email authentication]]</text>
    <sha1>19299174c6363f10ef81c59b0d66a4b2beba0391</sha1>
  </revision>
  <revision>
    <id>1580</id>
    <parentid>1579</parentid>
    <timestamp>2013-02-13T13:49:25Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>more links</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="857" xml:space="preserve">Here are the '''mail flows''' pictures.  Links to pdf files are provided.

==Original==
[[File:mailflows-0.png|frame|none|The original design by Patrik Fältström. &lt;span style="float: right;"&gt;[{{SERVER}}/mailflows-0.pdf pdf]&lt;/span&gt;]]


==Revised==
[[File:mailflows-1.png|frame|none|The revised version, unknown author. &lt;span style="float: right;"&gt;[{{SERVER}}/mailflows-1.pdf pdf]&lt;/span&gt;]]

==More links==
A derivative of those figures is used to illustrate [[wp:Email authentication]].

Patrik presented the underlying analysis at the [http://www.ripe.net/ripe/meetings/ripe-meetings/ripe-47/presentations RIPE47 EOF], January 2004, with these [http://meetings.ripe.net/ripe-47/presentations/ripe47-eof-spam.pdf slides], and at the [http://csrc.nist.gov/spam/ SPAM Technology Workshop], February 2004, with these [http://csrc.nist.gov/spam/paf.pdf slides].</text>
    <sha1>f064992d7f529be80fcfee597eb51948369e3bbf</sha1>
  </revision>
</page>
<page arvcontinue="20101017125844|1559">
  <title>Water tight opt-in</title>
  <ns>0</ns>
  <id>40</id>
  <revision>
    <id>1583</id>
    <timestamp>2013-12-17T15:00:37Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>New page</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="1828" xml:space="preserve">'''Water tight opt-in''' is one such that the three parties involved —sender, receiver, and user— can manage subscriptions.

==Web subscription form==
Web subscription forms would be changed from a single-step "enter your email to subscribe" to a two-step "enter your mail domain" + "enter your local-part".

An additional ''method'' input can let the user decide what action should be taken.  Otherwise, if the user enters no at-sign (@) it can be assumed that the value given is a domain.  Receiving software usually checks whether the domain has an &lt;code&gt;MX&lt;/code&gt; record.  In addition, it can check if it offers the well-known service described below.

If the domain doesn't provide the well-known service, or if it fails the initial step, then the wannabe sender asks for the local part of the user's email address, and proceeds as usual from there.

==Well known service==
Through this service, a client can learn how to have a confirmation form presented to a user.  The confirmation form would behave like a Paypal login-and-pay form.  The user logs in and confirm subscription to a given mail stream.

The mail stream provided by the wannabe sender can be characterized by several items, such as:
* '''Originating domain''' which shall be authenticated,
* '''List-Id''' or similar token, possibly matching the domain.

The user can specify further details, such as:
* '''Expiration date''' of the subscription,
* '''max number of messages''' that will be accepted,
* '''IMAP folder''' where mail from that stream will be delivered,
* '''concealed local part''' that will be returned to the wannabe sender.

The user's mailbox provider would return a subscription request to the sender, unless the user cancels the operation.  The request shall be digitally signed, and can thus be exhibited to an ESP or to a court.</text>
    <sha1>54dd879a6248f95b2507327eb4c42118ec46ec5e</sha1>
  </revision>
  <revision>
    <id>1584</id>
    <parentid>1583</parentid>
    <timestamp>2013-12-18T08:51:46Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Well known service */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2677" xml:space="preserve">'''Water tight opt-in''' is one such that the three parties involved —sender, receiver, and user— can manage subscriptions.

==Web subscription form==
Web subscription forms would be changed from a single-step "enter your email to subscribe" to a two-step "enter your mail domain" + "enter your local-part".

An additional ''method'' input can let the user decide what action should be taken.  Otherwise, if the user enters no at-sign (@) it can be assumed that the value given is a domain.  Receiving software usually checks whether the domain has an &lt;code&gt;MX&lt;/code&gt; record.  In addition, it can check if it offers the well-known service described below.

If the domain doesn't provide the well-known service, or if it fails the initial step, then the wannabe sender asks for the local part of the user's email address, and proceeds as usual from there.

==Well known service==
Through this service, a client can learn how to have a confirmation form presented to a user.  The confirmation form would behave like a Paypal login-and-pay form.  The user logs in and confirm subscription to a given mail stream.

The mail stream provided by the wannabe sender can be characterized by several items, such as:
* ''Originating domain'' which shall be authenticated,
* ''List-Id'' or similar token, possibly matching the domain.

The user can specify further details, such as:
* ''Expiration date'' of the subscription,
* ''max number of messages'' that will be accepted,
* ''IMAP folder'' where mail from that stream will be delivered,
* ''concealed local part'' that will return a disposable address to the wannabe sender.

The user's mailbox provider would return a subscription request to the sender, unless the user cancels the operation.  The request shall be digitally signed, and can thus be exhibited to an ESP or to a court.

==One-sided implementations==
A mailbox provider can develop (part of) the required functionality as an interface for creating disposable email addresses.  A sort of protocol for doing so is used by [https://ssl.trashmail.net/ TrashMail], who also distribute a FireFox add-on and a PHP script.  It currently features the following fields:
* ''Creation date'' of the entry,
* ''disposable address'' returned to the sender,
* ''destination'' address or folder,
* ''description'' by the tool that created the entry,
* ''number of messages'' remaining,
* ''expiration date'',
* ''HTTP address'' of the page that contained the subscription form, and
* ''whitelisting'' options.

For that to evolve into cooperative functionality, there needs to be a relationship between the submission form and the List-Id or similar identifier of the mail stream.</text>
    <sha1>3e31e85a254b587cafd269fde2f5769930339a32</sha1>
  </revision>
  <revision>
    <id>1585</id>
    <parentid>1584</parentid>
    <timestamp>2013-12-18T09:17:01Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Well known service */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2775" xml:space="preserve">'''Water tight opt-in''' is one such that the three parties involved —sender, receiver, and user— can manage subscriptions.

==Web subscription form==
Web subscription forms would be changed from a single-step "enter your email to subscribe" to a two-step "enter your mail domain" + "enter your local-part".

An additional ''method'' input can let the user decide what action should be taken.  Otherwise, if the user enters no at-sign (@) it can be assumed that the value given is a domain.  Receiving software usually checks whether the domain has an &lt;code&gt;MX&lt;/code&gt; record.  In addition, it can check if it offers the well-known service described below.

If the domain doesn't provide the well-known service, or if it fails the initial step, then the wannabe sender asks for the local part of the user's email address, and proceeds as usual from there.

==Well known service==
Through this service, a client can learn how to have a confirmation form presented to a user.  The confirmation form would behave like a Paypal login-and-pay form.  The user logs in and confirm subscription to a given mail stream.

The mail stream provided by the wannabe sender can be characterized by several items, such as:
* ''expiration date'',
* ''domain'' where the mail stream originates from,
* ''List-Id'', possibly matching the domain, DKIM-signed.

The user can tweak the expiration date and specify further details, such as:
* ''max number of messages'' that will be accepted,
* ''IMAP folder'' where mail from that stream will be delivered,
* ''concealed local part'' that will return a disposable address to the wannabe sender.

The user's mailbox provider would return a subscription request to the sender, unless the user cancels the operation.  The request shall be digitally signed, and can thus be exhibited to an ESP or to a court.  (DKIM is not much useful for signing requests that way, because its key may suddenly expire.)

==One-sided implementations==
A mailbox provider can develop (part of) the required functionality as an interface for creating disposable email addresses.  A sort of protocol for doing so is used by [https://ssl.trashmail.net/ TrashMail], who also distribute a FireFox add-on and a PHP script.  It currently features the following fields:
* ''Creation date'' of the entry,
* ''disposable address'' returned to the sender,
* ''destination'' address or folder,
* ''description'' by the tool that created the entry,
* ''number of messages'' remaining,
* ''expiration date'',
* ''HTTP address'' of the page that contained the subscription form, and
* ''whitelisting'' options.

For that to evolve into cooperative functionality, there needs to be a relationship between the submission form and the List-Id or similar identifier of the mail stream.</text>
    <sha1>986dfd5d7ac54a51aaf3270b597b730f48b038da</sha1>
  </revision>
  <revision>
    <id>1586</id>
    <parentid>1585</parentid>
    <timestamp>2013-12-23T11:56:45Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* One-sided implementations */ chicken and egg</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="2993" xml:space="preserve">'''Water tight opt-in''' is one such that the three parties involved —sender, receiver, and user— can manage subscriptions.

==Web subscription form==
Web subscription forms would be changed from a single-step "enter your email to subscribe" to a two-step "enter your mail domain" + "enter your local-part".

An additional ''method'' input can let the user decide what action should be taken.  Otherwise, if the user enters no at-sign (@) it can be assumed that the value given is a domain.  Receiving software usually checks whether the domain has an &lt;code&gt;MX&lt;/code&gt; record.  In addition, it can check if it offers the well-known service described below.

If the domain doesn't provide the well-known service, or if it fails the initial step, then the wannabe sender asks for the local part of the user's email address, and proceeds as usual from there.

==Well known service==
Through this service, a client can learn how to have a confirmation form presented to a user.  The confirmation form would behave like a Paypal login-and-pay form.  The user logs in and confirm subscription to a given mail stream.

The mail stream provided by the wannabe sender can be characterized by several items, such as:
* ''expiration date'',
* ''domain'' where the mail stream originates from,
* ''List-Id'', possibly matching the domain, DKIM-signed.

The user can tweak the expiration date and specify further details, such as:
* ''max number of messages'' that will be accepted,
* ''IMAP folder'' where mail from that stream will be delivered,
* ''concealed local part'' that will return a disposable address to the wannabe sender.

The user's mailbox provider would return a subscription request to the sender, unless the user cancels the operation.  The request shall be digitally signed, and can thus be exhibited to an ESP or to a court.  (DKIM is not much useful for signing requests that way, because its key may suddenly expire.)

==One-sided implementations==
A mailbox provider can develop (part of) the required functionality as an interface for creating disposable email addresses.  A sort of protocol for doing so is used by [https://ssl.trashmail.net/ TrashMail], who also distribute a FireFox add-on and a PHP script.  It currently features the following fields:
* ''Creation date'' of the entry,
* ''disposable address'' returned to the sender,
* ''destination'' address or folder,
* ''description'' by the tool that created the entry,
* ''number of messages'' remaining,
* ''expiration date'',
* ''HTTP address'' of the page that contained the subscription form, and
* ''whitelisting'' options.

For that to evolve into cooperative functionality, there needs to be a relationship between the submission form and the List-Id or similar identifier of the mail stream.

On the other hand, a marketer would probably not develop any kind of stuff without some minimal support from some relevant number of receivers.  It seems more likely that mailbox providers have to be the first mover.</text>
    <sha1>06be7d95eab02a4e4645acae4073b9249999bebb</sha1>
  </revision>
  <revision>
    <id>1587</id>
    <parentid>1586</parentid>
    <timestamp>2014-01-06T11:52:56Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Clarifications</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5818" xml:space="preserve">'''Water tight opt-in''' is an opt-in that involves three parties —''sender'', ''receiver'', and ''recipient''.  It uses disposable addresses (a.k.a. tagged addresses) and web forms.

Definitions:
* The '''recipient''' is the person who is subscribing to a given list,
* the '''receiver''' is her [[wp:Mailbox provider|mailbox provider]],
* the '''sender''' is the list manager, which also manages, directly or indirectly, the  web form through which the receiver's address is collected.

==Difference w.r.t. usual Confirmed Opt-In (COI)==
* The recipient delegates to the receiver part of subscription management.  This explicitly allows the receiver to learn the details of the recipient's subscriptions (thanks to Richard Clayton for this note.)

* The recipient is authenticated by the receiver when she states her will to subscribe.  Details of the subscription, such as how long it should last for and whether to use a newly created disposable address, have configurable default values which can be changed during the subscription process.

* The sender has a chance to skip COI, since the receiver statement suffices.  The sender can collect a digital copy of such statement, signed by the mailbox provider.

* The receiver maintains a database of the recipient's subscriptions, whereby she can manage them.

==How does it work==
The recipient interacts with the receiver via another web form, or via a browser add-on.  A cooperating sender prepares its web form so as to ease the subscription process; for example, the sender's web form can include a special javascript function that brings up the receiver's web form after the recipient fills in the domain name of the receiver —that is, an email address without an at-sign (&lt;code&gt;@&lt;/code&gt;).  If the domain does not support water tight opt-in, the function will ask the recipient to enter the local part of her address as well.

For non-cooperating senders, the recipient has to invoke the receiver's web form by herself.  This task can be eased by an add-on, as described [[#One-sided implementations|below]].

==Never type an email address in a web form any more==
Logging in on the receiver's web form should make use of form autofill features, unless the recipient uses someone else's browser.  Classical mailing lists use a mail-based subscription mechanism (otherwise see [[#Discussion lists|below]].)

By the same rationale that users have been advised not to publish an email address in a web page, users have to be advised neither to type their address into one.  Indeed, there is not much difference, except that regular web pages need to wait for a spammer to harvest the addresses written therein, while many web forms are directly connected to the spammer's processor.

'''Note''': We mean no disrespect by using the term ''spammer''.  Bulk email is here and won't go away, whereas ''unsolicited'' has such a subtle meaning that it can often be applied to whatever message, irrespectively of it being wanted or not, useful or not, necessary or not.  There are unlawful, criminal spammers, but there are legitimate, honest ones.  ''Marketer'' may be a more formal term for the latter ones.

==Well known service==
Through this service, a client can learn how to have a confirmation form presented to a user.  The confirmation form would behave like a Paypal login-and-pay form.  The user logs in and confirm subscription to a given mail stream.

The mail stream provided by the wannabe sender can be characterized by several items, such as:
* ''expiration date'',
* ''domain'' where the mail stream originates from,
* ''List-Id'', possibly matching the domain, DKIM-signed.

The user can tweak the expiration date and specify further details, such as:
* ''max number of messages'' that will be accepted,
* ''IMAP folder'' where mail from that stream will be delivered,
* ''concealed local part'' that will return a disposable address to the wannabe sender.

The user's mailbox provider would return a subscription request to the sender, unless the user cancels the operation.  The request shall be digitally signed, and can thus be exhibited to an ESP or to a court.  (DKIM is not much useful for signing requests that way, because its key may suddenly expire.)

==One-sided implementations==
A mailbox provider can develop (part of) the required functionality as an interface for creating disposable email addresses.  A sort of protocol for doing so is used by [https://ssl.trashmail.net/ TrashMail], who also distribute a FireFox add-on and a PHP script.  It currently features the following fields:
* ''Creation date'' of the entry,
* ''disposable address'' returned to the sender,
* ''destination'' address or folder,
* ''description'' by the tool that created the entry,
* ''number of messages'' remaining,
* ''expiration date'',
* ''HTTP address'' of the page that contained the subscription form, and
* ''whitelisting'' options.

For that to evolve into cooperative functionality, there needs to be a relationship between the submission form and the List-Id or similar identifier of the mail stream.

On the other hand, a marketer would probably not develop any kind of stuff without some minimal support from some relevant number of receivers.  It seems more likely that mailbox providers have to be the first mover.

==Discussion lists==
Discussion lists that present a web interface should perhaps discourage subscribers from using an anonymous disposable address, because that address will be made known to all other subscribed users, who may reply privately and store it in their address books.

List for discussing this particular subject include:
* [http://lists.services.net/cgi-bin/mj_wwwusr/domain=lists.gurus.org?user=&amp;passw=&amp;func=lists-long-full&amp;extra=asrg ASRG],
* [https://spammers.dontlike.us/mailman/listinfo/list SDLU].</text>
    <sha1>aee74c8c909b31bab7eb63be491edd538d6ffe22</sha1>
  </revision>
  <revision>
    <id>1588</id>
    <parentid>1587</parentid>
    <timestamp>2014-01-06T12:01:57Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <minor/>
    <comment>typos</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5805" xml:space="preserve">'''Water tight opt-in''' is an opt-in that involves three parties —''sender'', ''receiver'', and ''recipient''.  It uses disposable addresses (a.k.a. tagged addresses) and web forms.

Definitions:
* The '''recipient''' is the person who is subscribing to a given list,
* the '''receiver''' is her [[wp:Mailbox provider|mailbox provider]],
* the '''sender''' is the list manager, which also manages, directly or indirectly, the  web form through which the recipient's address is collected.

==Difference w.r.t. usual Confirmed Opt-In (COI)==
* The recipient delegates to the receiver part of subscription management.  This explicitly allows the receiver to learn the details of the recipient's subscriptions (thanks to Richard Clayton for this note.)

* The recipient is authenticated by the receiver when she states her will to subscribe.  Details of the subscription, such as how long it should last for and whether to use a newly created disposable address, have configurable default values which can be changed during the subscription process.

* The sender has a chance to skip COI, since the recipient statement suffices.  The sender can collect a digital copy of such statement, signed by the mailbox provider.

* The receiver maintains a database of the recipient's subscriptions, whereby she can manage them.

==How does it work==
The recipient interacts with the receiver via another web form, or via a browser add-on.  A cooperating sender prepares its web form so as to ease the subscription process; for example, the sender's web form can include a special javascript function that brings up the receiver's web form after the recipient fills in the domain name —that is, an email address without an at-sign (&lt;code&gt;@&lt;/code&gt;).  If the domain does not support water tight opt-in, the function will ask the recipient to enter the local part of her address as well.

For non-cooperating senders, the recipient has to invoke the receiver's web form by herself.  This task can be eased by an add-on, as described [[#One-sided implementations|below]].

==Never type an email address in a web form any more==
Logging in on the receiver's web form should make use of form autofill features, unless the recipient uses someone else's browser.  Classical mailing lists use a mail-based subscription mechanism (otherwise see [[#Discussion lists|below]].)

By the same rationale that users have been advised not to publish an email address in a web page, users have to be advised neither to type their address into one.  Indeed, there is not much difference, except that regular web pages need to wait for a spammer to harvest the addresses written therein, while many web forms are directly connected to the spammer's processor.

'''Note''': We mean no disrespect by using the term ''spammer''.  Bulk email is here and won't go away, whereas ''unsolicited'' has such a subtle meaning that it can often be applied to whatever message, irrespectively of it being wanted or not, useful or not, necessary or not.  There are unlawful, criminal spammers, but there are legitimate, honest ones.  ''Marketer'' may be a more formal term for the latter ones.

==Well known service==
Through this service, a client can learn how to have a confirmation form presented to a user.  The confirmation form would behave like a Paypal login-and-pay form.  The user logs in and confirms subscription to a given mail stream.

The mail stream provided by the wannabe sender can be characterized by several items, such as:
* ''expiration date'',
* ''domain'' where the mail stream originates from,
* ''List-Id'', possibly matching the domain, DKIM-signed.

The user can tweak the expiration date and specify further details, such as:
* ''max number of messages'' that will be accepted,
* ''IMAP folder'' where mail from that stream will be delivered,
* ''concealed local part'' that will return a disposable address to the wannabe sender.

The user's mailbox provider would return a subscription request to the sender, unless the user cancels the operation.  The request shall be digitally signed, and can thus be exhibited to an ESP or to a court.  (DKIM is not much useful for signing requests that way, because its key may suddenly expire.)

==One-sided implementations==
A mailbox provider can develop (part of) the required functionality as an interface for creating disposable email addresses.  A sort of protocol for doing so is used by [https://ssl.trashmail.net/ TrashMail], who also distribute a FireFox add-on and a PHP script.  It currently features the following fields:
* ''Creation date'' of the entry,
* ''disposable address'' returned to the sender,
* ''destination'' address or folder,
* ''description'' by the tool that created the entry,
* ''number of messages'' remaining,
* ''expiration date'',
* ''HTTP address'' of the page that contained the subscription form, and
* ''whitelisting'' options.

For that to evolve into cooperative functionality, there needs to be a relationship between the submission form and the List-Id or similar identifier of the mail stream.

On the other hand, a marketer would probably not develop any kind of stuff without some minimal support from some relevant number of receivers.  It seems more likely that mailbox providers have to be the first mover.

==Discussion lists==
Discussion lists that present a web interface should perhaps discourage subscribers from using an anonymous disposable address, because that address will be made known to all other subscribed users, who may reply privately and store it in their address books.

List for discussing this particular subject include:
* [http://lists.services.net/cgi-bin/mj_wwwusr/domain=lists.gurus.org?user=&amp;passw=&amp;func=lists-long-full&amp;extra=asrg ASRG],
* [https://spammers.dontlike.us/mailman/listinfo/list SDLU].</text>
    <sha1>b7b0c8bca7ff84f1729d922534f7b367042a3262</sha1>
  </revision>
  <revision>
    <id>1589</id>
    <parentid>1588</parentid>
    <timestamp>2014-01-07T16:07:04Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Patents */ new section</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="5966" xml:space="preserve">'''Water tight opt-in''' is an opt-in that involves three parties —''sender'', ''receiver'', and ''recipient''.  It uses disposable addresses (a.k.a. tagged addresses) and web forms.

Definitions:
* The '''recipient''' is the person who is subscribing to a given list,
* the '''receiver''' is her [[wp:Mailbox provider|mailbox provider]],
* the '''sender''' is the list manager, which also manages, directly or indirectly, the  web form through which the recipient's address is collected.

==Difference w.r.t. usual Confirmed Opt-In (COI)==
* The recipient delegates to the receiver part of subscription management.  This explicitly allows the receiver to learn the details of the recipient's subscriptions (thanks to Richard Clayton for this note.)

* The recipient is authenticated by the receiver when she states her will to subscribe.  Details of the subscription, such as how long it should last for and whether to use a newly created disposable address, have configurable default values which can be changed during the subscription process.

* The sender has a chance to skip COI, since the recipient statement suffices.  The sender can collect a digital copy of such statement, signed by the mailbox provider.

* The receiver maintains a database of the recipient's subscriptions, whereby she can manage them.

==How does it work==
The recipient interacts with the receiver via another web form, or via a browser add-on.  A cooperating sender prepares its web form so as to ease the subscription process; for example, the sender's web form can include a special javascript function that brings up the receiver's web form after the recipient fills in the domain name —that is, an email address without an at-sign (&lt;code&gt;@&lt;/code&gt;).  If the domain does not support water tight opt-in, the function will ask the recipient to enter the local part of her address as well.

For non-cooperating senders, the recipient has to invoke the receiver's web form by herself.  This task can be eased by an add-on, as described [[#One-sided implementations|below]].

==Never type an email address in a web form any more==
Logging in on the receiver's web form should make use of form autofill features, unless the recipient uses someone else's browser.  Classical mailing lists use a mail-based subscription mechanism (otherwise see [[#Discussion lists|below]].)

By the same rationale that users have been advised not to publish an email address in a web page, users have to be advised neither to type their address into one.  Indeed, there is not much difference, except that regular web pages need to wait for a spammer to harvest the addresses written therein, while many web forms are directly connected to the spammer's processor.

'''Note''': We mean no disrespect by using the term ''spammer''.  Bulk email is here and won't go away, whereas ''unsolicited'' has such a subtle meaning that it can often be applied to whatever message, irrespectively of it being wanted or not, useful or not, necessary or not.  There are unlawful, criminal spammers, but there are legitimate, honest ones.  ''Marketer'' may be a more formal term for the latter ones.

==Well known service==
Through this service, a client can learn how to have a confirmation form presented to a user.  The confirmation form would behave like a Paypal login-and-pay form.  The user logs in and confirms subscription to a given mail stream.

The mail stream provided by the wannabe sender can be characterized by several items, such as:
* ''expiration date'',
* ''domain'' where the mail stream originates from,
* ''List-Id'', possibly matching the domain, DKIM-signed.

The user can tweak the expiration date and specify further details, such as:
* ''max number of messages'' that will be accepted,
* ''IMAP folder'' where mail from that stream will be delivered,
* ''concealed local part'' that will return a disposable address to the wannabe sender.

The user's mailbox provider would return a subscription request to the sender, unless the user cancels the operation.  The request shall be digitally signed, and can thus be exhibited to an ESP or to a court.  (DKIM is not much useful for signing requests that way, because its key may suddenly expire.)

==One-sided implementations==
A mailbox provider can develop (part of) the required functionality as an interface for creating disposable email addresses.  A sort of protocol for doing so is used by [https://ssl.trashmail.net/ TrashMail], who also distribute a FireFox add-on and a PHP script.  It currently features the following fields:
* ''Creation date'' of the entry,
* ''disposable address'' returned to the sender,
* ''destination'' address or folder,
* ''description'' by the tool that created the entry,
* ''number of messages'' remaining,
* ''expiration date'',
* ''HTTP address'' of the page that contained the subscription form, and
* ''whitelisting'' options.

For that to evolve into cooperative functionality, there needs to be a relationship between the submission form and the List-Id or similar identifier of the mail stream.

On the other hand, a marketer would probably not develop any kind of stuff without some minimal support from some relevant number of receivers.  It seems more likely that mailbox providers have to be the first mover.

==Patents==
Channelized addresses were described by Robert J. Hall, who filed patent [https://www.google.com/patents/US5930479 US 5930479] on October 21, 1996.

==Discussion lists==
Discussion lists that present a web interface should perhaps discourage subscribers from using an anonymous disposable address, because that address will be made known to all other subscribed users, who may reply privately and store it in their address books.

List for discussing this particular subject include:
* [http://lists.services.net/cgi-bin/mj_wwwusr/domain=lists.gurus.org?user=&amp;passw=&amp;func=lists-long-full&amp;extra=asrg ASRG],
* [https://spammers.dontlike.us/mailman/listinfo/list SDLU].</text>
    <sha1>b0ccceaa9085b3f33584e6e13d8504f8f68fa8aa</sha1>
  </revision>
  <revision>
    <id>1590</id>
    <parentid>1589</parentid>
    <timestamp>2014-01-07T16:11:16Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Caveats */ new section</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6515" xml:space="preserve">'''Water tight opt-in''' is an opt-in that involves three parties —''sender'', ''receiver'', and ''recipient''.  It uses disposable addresses (a.k.a. tagged addresses) and web forms.

Definitions:
* The '''recipient''' is the person who is subscribing to a given list,
* the '''receiver''' is her [[wp:Mailbox provider|mailbox provider]],
* the '''sender''' is the list manager, which also manages, directly or indirectly, the  web form through which the recipient's address is collected.

==Difference w.r.t. usual Confirmed Opt-In (COI)==
* The recipient delegates to the receiver part of subscription management.  This explicitly allows the receiver to learn the details of the recipient's subscriptions (thanks to Richard Clayton for this note.)

* The recipient is authenticated by the receiver when she states her will to subscribe.  Details of the subscription, such as how long it should last for and whether to use a newly created disposable address, have configurable default values which can be changed during the subscription process.

* The sender has a chance to skip COI, since the recipient statement suffices.  The sender can collect a digital copy of such statement, signed by the mailbox provider.

* The receiver maintains a database of the recipient's subscriptions, whereby she can manage them.

==How does it work==
The recipient interacts with the receiver via another web form, or via a browser add-on.  A cooperating sender prepares its web form so as to ease the subscription process; for example, the sender's web form can include a special javascript function that brings up the receiver's web form after the recipient fills in the domain name —that is, an email address without an at-sign (&lt;code&gt;@&lt;/code&gt;).  If the domain does not support water tight opt-in, the function will ask the recipient to enter the local part of her address as well.

For non-cooperating senders, the recipient has to invoke the receiver's web form by herself.  This task can be eased by an add-on, as described [[#One-sided implementations|below]].

==Never type an email address in a web form any more==
Logging in on the receiver's web form should make use of form autofill features, unless the recipient uses someone else's browser.  Classical mailing lists use a mail-based subscription mechanism (otherwise see [[#Discussion lists|below]].)

By the same rationale that users have been advised not to publish an email address in a web page, users have to be advised neither to type their address into one.  Indeed, there is not much difference, except that regular web pages need to wait for a spammer to harvest the addresses written therein, while many web forms are directly connected to the spammer's processor.

'''Note''': We mean no disrespect by using the term ''spammer''.  Bulk email is here and won't go away, whereas ''unsolicited'' has such a subtle meaning that it can often be applied to whatever message, irrespectively of it being wanted or not, useful or not, necessary or not.  There are unlawful, criminal spammers, but there are legitimate, honest ones.  ''Marketer'' may be a more formal term for the latter ones.

==Well known service==
Through this service, a client can learn how to have a confirmation form presented to a user.  The confirmation form would behave like a Paypal login-and-pay form.  The user logs in and confirms subscription to a given mail stream.

The mail stream provided by the wannabe sender can be characterized by several items, such as:
* ''expiration date'',
* ''domain'' where the mail stream originates from,
* ''List-Id'', possibly matching the domain, DKIM-signed.

The user can tweak the expiration date and specify further details, such as:
* ''max number of messages'' that will be accepted,
* ''IMAP folder'' where mail from that stream will be delivered,
* ''concealed local part'' that will return a disposable address to the wannabe sender.

The user's mailbox provider would return a subscription request to the sender, unless the user cancels the operation.  The request shall be digitally signed, and can thus be exhibited to an ESP or to a court.  (DKIM is not much useful for signing requests that way, because its key may suddenly expire.)

==One-sided implementations==
A mailbox provider can develop (part of) the required functionality as an interface for creating disposable email addresses.  A sort of protocol for doing so is used by [https://ssl.trashmail.net/ TrashMail], who also distribute a FireFox add-on and a PHP script.  It currently features the following fields:
* ''Creation date'' of the entry,
* ''disposable address'' returned to the sender,
* ''destination'' address or folder,
* ''description'' by the tool that created the entry,
* ''number of messages'' remaining,
* ''expiration date'',
* ''HTTP address'' of the page that contained the subscription form, and
* ''whitelisting'' options.

For that to evolve into cooperative functionality, there needs to be a relationship between the submission form and the List-Id or similar identifier of the mail stream.

On the other hand, a marketer would probably not develop any kind of stuff without some minimal support from some relevant number of receivers.  It seems more likely that mailbox providers have to be the first mover.

==Caveats==
Care must be taken to implement a foolproof system.  At a first glance, it might make sense to use an email address that expires after a month for a one-off purpose from a web store.  Except that sometimes the customer might like the purchase so much, they decide to buy more stuff, only to find out the order confirmation emails stop arriving.  Or the store might have a good reason to contact the consumer - a data breach, a fault discovered in the product - and the emails fail to arrive.  (Thanks to Martijn Grooten for this hint.)

==Patents==
Channelized addresses were described by Robert J. Hall, who filed patent [https://www.google.com/patents/US5930479 US 5930479] on October 21, 1996.

==Discussion lists==
Discussion lists that present a web interface should perhaps discourage subscribers from using an anonymous disposable address, because that address will be made known to all other subscribed users, who may reply privately and store it in their address books.

List for discussing this particular subject include:
* [http://lists.services.net/cgi-bin/mj_wwwusr/domain=lists.gurus.org?user=&amp;passw=&amp;func=lists-long-full&amp;extra=asrg ASRG],
* [https://spammers.dontlike.us/mailman/listinfo/list SDLU].</text>
    <sha1>d131993443e455c0a91a5dd7a01e2df6db717663</sha1>
  </revision>
  <revision>
    <id>1591</id>
    <parentid>1590</parentid>
    <timestamp>2014-01-10T08:26:10Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Discussion lists */ was</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6557" xml:space="preserve">'''Water tight opt-in''' is an opt-in that involves three parties —''sender'', ''receiver'', and ''recipient''.  It uses disposable addresses (a.k.a. tagged addresses) and web forms.

Definitions:
* The '''recipient''' is the person who is subscribing to a given list,
* the '''receiver''' is her [[wp:Mailbox provider|mailbox provider]],
* the '''sender''' is the list manager, which also manages, directly or indirectly, the  web form through which the recipient's address is collected.

==Difference w.r.t. usual Confirmed Opt-In (COI)==
* The recipient delegates to the receiver part of subscription management.  This explicitly allows the receiver to learn the details of the recipient's subscriptions (thanks to Richard Clayton for this note.)

* The recipient is authenticated by the receiver when she states her will to subscribe.  Details of the subscription, such as how long it should last for and whether to use a newly created disposable address, have configurable default values which can be changed during the subscription process.

* The sender has a chance to skip COI, since the recipient statement suffices.  The sender can collect a digital copy of such statement, signed by the mailbox provider.

* The receiver maintains a database of the recipient's subscriptions, whereby she can manage them.

==How does it work==
The recipient interacts with the receiver via another web form, or via a browser add-on.  A cooperating sender prepares its web form so as to ease the subscription process; for example, the sender's web form can include a special javascript function that brings up the receiver's web form after the recipient fills in the domain name —that is, an email address without an at-sign (&lt;code&gt;@&lt;/code&gt;).  If the domain does not support water tight opt-in, the function will ask the recipient to enter the local part of her address as well.

For non-cooperating senders, the recipient has to invoke the receiver's web form by herself.  This task can be eased by an add-on, as described [[#One-sided implementations|below]].

==Never type an email address in a web form any more==
Logging in on the receiver's web form should make use of form autofill features, unless the recipient uses someone else's browser.  Classical mailing lists use a mail-based subscription mechanism (otherwise see [[#Discussion lists|below]].)

By the same rationale that users have been advised not to publish an email address in a web page, users have to be advised neither to type their address into one.  Indeed, there is not much difference, except that regular web pages need to wait for a spammer to harvest the addresses written therein, while many web forms are directly connected to the spammer's processor.

'''Note''': We mean no disrespect by using the term ''spammer''.  Bulk email is here and won't go away, whereas ''unsolicited'' has such a subtle meaning that it can often be applied to whatever message, irrespectively of it being wanted or not, useful or not, necessary or not.  There are unlawful, criminal spammers, but there are legitimate, honest ones.  ''Marketer'' may be a more formal term for the latter ones.

==Well known service==
Through this service, a client can learn how to have a confirmation form presented to a user.  The confirmation form would behave like a Paypal login-and-pay form.  The user logs in and confirms subscription to a given mail stream.

The mail stream provided by the wannabe sender can be characterized by several items, such as:
* ''expiration date'',
* ''domain'' where the mail stream originates from,
* ''List-Id'', possibly matching the domain, DKIM-signed.

The user can tweak the expiration date and specify further details, such as:
* ''max number of messages'' that will be accepted,
* ''IMAP folder'' where mail from that stream will be delivered,
* ''concealed local part'' that will return a disposable address to the wannabe sender.

The user's mailbox provider would return a subscription request to the sender, unless the user cancels the operation.  The request shall be digitally signed, and can thus be exhibited to an ESP or to a court.  (DKIM is not much useful for signing requests that way, because its key may suddenly expire.)

==One-sided implementations==
A mailbox provider can develop (part of) the required functionality as an interface for creating disposable email addresses.  A sort of protocol for doing so is used by [https://ssl.trashmail.net/ TrashMail], who also distribute a FireFox add-on and a PHP script.  It currently features the following fields:
* ''Creation date'' of the entry,
* ''disposable address'' returned to the sender,
* ''destination'' address or folder,
* ''description'' by the tool that created the entry,
* ''number of messages'' remaining,
* ''expiration date'',
* ''HTTP address'' of the page that contained the subscription form, and
* ''whitelisting'' options.

For that to evolve into cooperative functionality, there needs to be a relationship between the submission form and the List-Id or similar identifier of the mail stream.

On the other hand, a marketer would probably not develop any kind of stuff without some minimal support from some relevant number of receivers.  It seems more likely that mailbox providers have to be the first mover.

==Caveats==
Care must be taken to implement a foolproof system.  At a first glance, it might make sense to use an email address that expires after a month for a one-off purpose from a web store.  Except that sometimes the customer might like the purchase so much, they decide to buy more stuff, only to find out the order confirmation emails stop arriving.  Or the store might have a good reason to contact the consumer - a data breach, a fault discovered in the product - and the emails fail to arrive.  (Thanks to Martijn Grooten for this hint.)

==Patents==
Channelized addresses were described by Robert J. Hall, who filed patent [https://www.google.com/patents/US5930479 US 5930479] on October 21, 1996.

==Discussion lists==
Discussion lists that present a web interface should perhaps discourage subscribers from using an anonymous disposable address, because that address will be made known to all other subscribed users, who may reply privately and store it in their address books.

This particular subject was discussed in the following lists (in reverse chronological order):
* [http://lists.services.net/cgi-bin/mj_wwwusr/domain=lists.gurus.org?user=&amp;passw=&amp;func=lists-long-full&amp;extra=asrg ASRG],
* [https://spammers.dontlike.us/mailman/listinfo/list SDLU].</text>
    <sha1>23ebe99c3652799613c09f8af4019af43c2db136</sha1>
  </revision>
  <revision>
    <id>1592</id>
    <parentid>1591</parentid>
    <timestamp>2014-01-10T08:34:59Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Discussion lists */ dates</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6724" xml:space="preserve">'''Water tight opt-in''' is an opt-in that involves three parties —''sender'', ''receiver'', and ''recipient''.  It uses disposable addresses (a.k.a. tagged addresses) and web forms.

Definitions:
* The '''recipient''' is the person who is subscribing to a given list,
* the '''receiver''' is her [[wp:Mailbox provider|mailbox provider]],
* the '''sender''' is the list manager, which also manages, directly or indirectly, the  web form through which the recipient's address is collected.

==Difference w.r.t. usual Confirmed Opt-In (COI)==
* The recipient delegates to the receiver part of subscription management.  This explicitly allows the receiver to learn the details of the recipient's subscriptions (thanks to Richard Clayton for this note.)

* The recipient is authenticated by the receiver when she states her will to subscribe.  Details of the subscription, such as how long it should last for and whether to use a newly created disposable address, have configurable default values which can be changed during the subscription process.

* The sender has a chance to skip COI, since the recipient statement suffices.  The sender can collect a digital copy of such statement, signed by the mailbox provider.

* The receiver maintains a database of the recipient's subscriptions, whereby she can manage them.

==How does it work==
The recipient interacts with the receiver via another web form, or via a browser add-on.  A cooperating sender prepares its web form so as to ease the subscription process; for example, the sender's web form can include a special javascript function that brings up the receiver's web form after the recipient fills in the domain name —that is, an email address without an at-sign (&lt;code&gt;@&lt;/code&gt;).  If the domain does not support water tight opt-in, the function will ask the recipient to enter the local part of her address as well.

For non-cooperating senders, the recipient has to invoke the receiver's web form by herself.  This task can be eased by an add-on, as described [[#One-sided implementations|below]].

==Never type an email address in a web form any more==
Logging in on the receiver's web form should make use of form autofill features, unless the recipient uses someone else's browser.  Classical mailing lists use a mail-based subscription mechanism (otherwise see [[#Discussion lists|below]].)

By the same rationale that users have been advised not to publish an email address in a web page, users have to be advised neither to type their address into one.  Indeed, there is not much difference, except that regular web pages need to wait for a spammer to harvest the addresses written therein, while many web forms are directly connected to the spammer's processor.

'''Note''': We mean no disrespect by using the term ''spammer''.  Bulk email is here and won't go away, whereas ''unsolicited'' has such a subtle meaning that it can often be applied to whatever message, irrespectively of it being wanted or not, useful or not, necessary or not.  There are unlawful, criminal spammers, but there are legitimate, honest ones.  ''Marketer'' may be a more formal term for the latter ones.

==Well known service==
Through this service, a client can learn how to have a confirmation form presented to a user.  The confirmation form would behave like a Paypal login-and-pay form.  The user logs in and confirms subscription to a given mail stream.

The mail stream provided by the wannabe sender can be characterized by several items, such as:
* ''expiration date'',
* ''domain'' where the mail stream originates from,
* ''List-Id'', possibly matching the domain, DKIM-signed.

The user can tweak the expiration date and specify further details, such as:
* ''max number of messages'' that will be accepted,
* ''IMAP folder'' where mail from that stream will be delivered,
* ''concealed local part'' that will return a disposable address to the wannabe sender.

The user's mailbox provider would return a subscription request to the sender, unless the user cancels the operation.  The request shall be digitally signed, and can thus be exhibited to an ESP or to a court.  (DKIM is not much useful for signing requests that way, because its key may suddenly expire.)

==One-sided implementations==
A mailbox provider can develop (part of) the required functionality as an interface for creating disposable email addresses.  A sort of protocol for doing so is used by [https://ssl.trashmail.net/ TrashMail], who also distribute a FireFox add-on and a PHP script.  It currently features the following fields:
* ''Creation date'' of the entry,
* ''disposable address'' returned to the sender,
* ''destination'' address or folder,
* ''description'' by the tool that created the entry,
* ''number of messages'' remaining,
* ''expiration date'',
* ''HTTP address'' of the page that contained the subscription form, and
* ''whitelisting'' options.

For that to evolve into cooperative functionality, there needs to be a relationship between the submission form and the List-Id or similar identifier of the mail stream.

On the other hand, a marketer would probably not develop any kind of stuff without some minimal support from some relevant number of receivers.  It seems more likely that mailbox providers have to be the first mover.

==Caveats==
Care must be taken to implement a foolproof system.  At a first glance, it might make sense to use an email address that expires after a month for a one-off purpose from a web store.  Except that sometimes the customer might like the purchase so much, they decide to buy more stuff, only to find out the order confirmation emails stop arriving.  Or the store might have a good reason to contact the consumer - a data breach, a fault discovered in the product - and the emails fail to arrive.  (Thanks to Martijn Grooten for this hint.)

==Patents==
Channelized addresses were described by Robert J. Hall, who filed patent [https://www.google.com/patents/US5930479 US 5930479] on October 21, 1996.

==Discussion lists==
Discussion lists that present a web interface should perhaps discourage subscribers from using an anonymous disposable address, because that address will be made known to all other subscribed users, who may reply privately and store it in their address books.

==Discussion==
This particular subject was discussed in the following lists (in reverse chronological order):
* [http://lists.services.net/cgi-bin/mj_wwwusr/domain=lists.gurus.org?user=&amp;passw=&amp;func=lists-long-full&amp;extra=asrg ASRG], 21 dec 2013,
* [https://spammers.dontlike.us/mailman/listinfo/list SDLU], 16 dec 2013.
* [https://ssl.trashmail.net/forum/viewtopic.php?f=2&amp;t=5421&amp;start=24 Trashmail success and failure stories] forum, 6 dec 2013</text>
    <sha1>d792dcac1ae6f6854745862982e394ad24386e34</sha1>
  </revision>
  <revision>
    <id>1593</id>
    <parentid>1592</parentid>
    <timestamp>2014-01-15T08:50:00Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Implementation */ new section</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="6881" xml:space="preserve">'''Water tight opt-in''' is an opt-in that involves three parties —''sender'', ''receiver'', and ''recipient''.  It uses disposable addresses (a.k.a. tagged addresses) and web forms.

Definitions:
* The '''recipient''' is the person who is subscribing to a given list,
* the '''receiver''' is her [[wp:Mailbox provider|mailbox provider]],
* the '''sender''' is the list manager, which also manages, directly or indirectly, the  web form through which the recipient's address is collected.

==Difference w.r.t. usual Confirmed Opt-In (COI)==
* The recipient delegates to the receiver part of subscription management.  This explicitly allows the receiver to learn the details of the recipient's subscriptions (thanks to Richard Clayton for this note.)

* The recipient is authenticated by the receiver when she states her will to subscribe.  Details of the subscription, such as how long it should last for and whether to use a newly created disposable address, have configurable default values which can be changed during the subscription process.

* The sender has a chance to skip COI, since the recipient statement suffices.  The sender can collect a digital copy of such statement, signed by the mailbox provider.

* The receiver maintains a database of the recipient's subscriptions, whereby she can manage them.

==How does it work==
The recipient interacts with the receiver via another web form, or via a browser add-on.  A cooperating sender prepares its web form so as to ease the subscription process; for example, the sender's web form can include a special javascript function that brings up the receiver's web form after the recipient fills in the domain name —that is, an email address without an at-sign (&lt;code&gt;@&lt;/code&gt;).  If the domain does not support water tight opt-in, the function will ask the recipient to enter the local part of her address as well.

For non-cooperating senders, the recipient has to invoke the receiver's web form by herself.  This task can be eased by an add-on, as described [[#One-sided implementations|below]].

==Never type an email address in a web form any more==
Logging in on the receiver's web form should make use of form autofill features, unless the recipient uses someone else's browser.  Classical mailing lists use a mail-based subscription mechanism (otherwise see [[#Discussion lists|below]].)

By the same rationale that users have been advised not to publish an email address in a web page, users have to be advised neither to type their address into one.  Indeed, there is not much difference, except that regular web pages need to wait for a spammer to harvest the addresses written therein, while many web forms are directly connected to the spammer's processor.

'''Note''': We mean no disrespect by using the term ''spammer''.  Bulk email is here and won't go away, whereas ''unsolicited'' has such a subtle meaning that it can often be applied to whatever message, irrespectively of it being wanted or not, useful or not, necessary or not.  There are unlawful, criminal spammers, but there are legitimate, honest ones.  ''Marketer'' may be a more formal term for the latter ones.

==Well known service==
Through this service, a client can learn how to have a confirmation form presented to a user.  The confirmation form would behave like a Paypal login-and-pay form.  The user logs in and confirms subscription to a given mail stream.

The mail stream provided by the wannabe sender can be characterized by several items, such as:
* ''expiration date'',
* ''domain'' where the mail stream originates from,
* ''List-Id'', possibly matching the domain, DKIM-signed.

The user can tweak the expiration date and specify further details, such as:
* ''max number of messages'' that will be accepted,
* ''IMAP folder'' where mail from that stream will be delivered,
* ''concealed local part'' that will return a disposable address to the wannabe sender.

The user's mailbox provider would return a subscription request to the sender, unless the user cancels the operation.  The request shall be digitally signed, and can thus be exhibited to an ESP or to a court.  (DKIM is not much useful for signing requests that way, because its key may suddenly expire.)

==One-sided implementations==
A mailbox provider can develop (part of) the required functionality as an interface for creating disposable email addresses.  A sort of protocol for doing so is used by [https://ssl.trashmail.net/ TrashMail], who also distribute a FireFox add-on and a PHP script.  It currently features the following fields:
* ''Creation date'' of the entry,
* ''disposable address'' returned to the sender,
* ''destination'' address or folder,
* ''description'' by the tool that created the entry,
* ''number of messages'' remaining,
* ''expiration date'',
* ''HTTP address'' of the page that contained the subscription form, and
* ''whitelisting'' options.

For that to evolve into cooperative functionality, there needs to be a relationship between the submission form and the List-Id or similar identifier of the mail stream.

On the other hand, a marketer would probably not develop any kind of stuff without some minimal support from some relevant number of receivers.  It seems more likely that mailbox providers have to be the first mover.

==Caveats==
Care must be taken to implement a foolproof system.  At a first glance, it might make sense to use an email address that expires after a month for a one-off purpose from a web store.  Except that sometimes the customer might like the purchase so much, they decide to buy more stuff, only to find out the order confirmation emails stop arriving.  Or the store might have a good reason to contact the consumer - a data breach, a fault discovered in the product - and the emails fail to arrive.  (Thanks to Martijn Grooten for this hint.)

==Implementation==
* Javascript, obviously.
* Should use [[wp:Security Assertion Markup Language|SAML]] and/or [http://openid.net/connect/ OpenID Connect]?

==Patents==
Channelized addresses were described by Robert J. Hall, who filed patent [https://www.google.com/patents/US5930479 US 5930479] on October 21, 1996.

==Discussion lists==
Discussion lists that present a web interface should perhaps discourage subscribers from using an anonymous disposable address, because that address will be made known to all other subscribed users, who may reply privately and store it in their address books.

==Discussion==
This particular subject was discussed in the following lists (in reverse chronological order):
* [http://lists.services.net/cgi-bin/mj_wwwusr/domain=lists.gurus.org?user=&amp;passw=&amp;func=lists-long-full&amp;extra=asrg ASRG], 21 dec 2013,
* [https://spammers.dontlike.us/mailman/listinfo/list SDLU], 16 dec 2013.
* [https://ssl.trashmail.net/forum/viewtopic.php?f=2&amp;t=5421&amp;start=24 Trashmail success and failure stories] forum, 6 dec 2013</text>
    <sha1>f7e25720f034087d92138f893f432dd99ca7df82</sha1>
  </revision>
</page>
<page arvcontinue="20101017125844|1559">
  <title>standard behavior</title>
  <ns>0</ns>
  <id>32</id>
  <revision>
    <id>1601</id>
    <parentid>1546</parentid>
    <timestamp>2020-07-24T18:48:47Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>&lt;ref&gt; doesn't work, set parentheses instead</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7305" xml:space="preserve">'''Standard behavior''' illustrates email simple store and forward mechanisms, that have been devised long before privacy regulations. Here we describe the most usual patterns that a message may go through, highlighting the problem of managing personal data, a.k.a. personally identifiable data.

Except for the first case, direct delivering, ''store and forward'' involves multiple parties, and thereby involves privacy concerns.

==Direct personal message==
[[File:Normal-delivery.png|300px|thumb|left|Normal delivery]] Normal delivery accounts for the majority of messages. The illustration introduces the concepts of '''MSA''' (''Message Submission Agent'', a.k.a. outgoing mail server) and '''MX''' (''Mail eXchanger'', a.k.a. incoming mail server). All servers are labeled according to the first role they play along the illustrated message path. For example, the MSA also acts as a transmitter, as it determines the relevant destination server, and sends the message there.

The very format ''&amp;lt;recipient@domain&amp;gt;'' of email addresses implies there is an agreement between a recipient and the domain. It is assumed that such agreements cover any privacy concern.
&lt;br style="clear:both" /&gt;

==External forwarding==
[[File:Forward.png|300px|thumb|left|Forwarding to a different mail domain]] The original destination &lt;u&gt;''rcpt@domain''&lt;/u&gt; is replaced with &lt;u&gt;''rcpt@other-domain''&lt;/u&gt; by the &lt;u&gt;forwarding server&lt;/u&gt;. The new address is someone's personal data, and its owner deserves full access to it.

We call this ''external'' to distinguish it from role accounts, e.g. ''sales@domain'' and similar forwarding of messages within the same server or mail domain. While for internal forwarding we may assume adequate agreements between users and their mail domains, external organizations require their own agreements. We are not much interested in formal pieces of paper, but rather in the effective ability of users to control how their addresses are used.

Vanity domains' email addresses solely exist for forwarding. In most such cases, they feature full blown web applications that allow users to control their addresses. However, simple ''.forward'' files do not. (In a classical setting, ''.forward'' files live in users' home directories, and hence are under their complete control. Most current mail servers, however, work with ''virtual users'', an arrangement that allows better management and is safer for server's security. Access to ''.forward'' files is an oversight originating from the fact that the fundamental principle, that email addresses shall be under the complete control of their owners, although respected, was never made explicit in SMTP.) They are part of the recommended procedure for changing email address, which may well be considered a necessary part of the mail system.
&lt;br style="clear:both" /&gt;

==Newsletters and announcements==
[[File:List.png|300px|thumb|left|Newsletters and mailing lists]] Newsletters are the long established case where privacy rules get broken. Technically, they are the same as mailing lists. However, the semantics is very different. Most mailing list are very respectful of privacy: they require explicit user's subscription, which is double checked so that it is really difficult to subscribe someone else, and they regularly send unsubscribe instructions. Newsletters and single announcements are a means for advertising something, and only in a few cases they collect subscriptions regularly.

Authors submit the message to the list exploder for &lt;u&gt;''list@domain''&lt;/u&gt;. That is, they don't manually type addresses, nor select them from public directories, for each message they send. Rather, they maintain a database from which destination addresses can be extracted by the exploder using convenient criteria. Users shall be able to access the data records that concern them. However, seeking users' confirmation by sending them an email message upon insertion is grotesque, since message-sending is not yet confirmed.

Senders' requirement is to build those databases. In several cases, sending organizations lack the prestige, fame, and reputation for enticing users to subscribe spontaneously, and thus collect addresses in various ways. We are not much interested in ''how'' addresses are collected. However, there is a precise moment when an address is made available to an exploder, with given extraction criteria, a.k.a. profiles. An agreement with the subject must be sought after that moment, and before any message that matches those criteria is actually sent. Thus, automating this kind of agreement is apparently the kind of solution we seek. (Users might configure their preferences, on their mail servers, specifying what they wish to do for a [[forwarding agreement]] proposal that makes their mailbox the target of a given message or series of messages. For example, they might specify, for any category of message, whether they wish to automatically deny or accept the agreement, and how they'd like to be notified of this fact. Categories of messages might be defined by means of ''Solicitation-keywords'', as defined in RFC 3865.)
&lt;br style="clear:both" /&gt;

==External backup MX==
[[File:Backup-mx.png|300px|thumb|left|Primary mail exchanger is unreachable, message is delivered through a backup MX]] It used to be rather common to have ''external'' backup MXes. These were machines configured to accept mail for a different domain, without being able to state the validity of its addresses. They should only be used when the main (or primary) server experiences a network outage.

Nowadays, organizations that operate on a single network have given up using backup MXes. Until networks work reliably, they are not needed. Old-style backup MXes accept messages destined to ''non-existent@domain'', and attempt to send them to the main server, with embarrassing behavior about delivery status notifications. Larger organizations distribute their users' data so that any server can determine whether a mailbox exists. If they are distributed evenly around the globe, their mail systems may work even in case solar flares tamper with telecommunications.

Backup MXes operated by 3rd parties pose a problem that has a common facet with that of newsletters. Assume a backup MX has been fed with a hashed list of addresses; that is, it can compute a one-way hash of any address so as to determine whether it is listed. Since addresses are hidden, such feed doesn't require special interaction with each subject, although proper notification is appropriate. When the backup MX learns of the existence of one of those addresses --after a positive lookup-- it moves it from the hashed list and makes it available on a cleartext one: on performing such operation, it is in the same condition of a newsletter exploder acquiring a new address, therefore it can solve the problem by the same means.
&lt;br style="clear:both" /&gt;

==Conclusions==
Getting into an agreement would not be a tough procedure if there is a standard way to automate it.  The [[solution proposed]] provides for procedures to automatically negotiate agreements, and manage the required passwords for ''SMTP Authentication''.  As a result, MX servers will have lists of effective agreements, that they can put in the hands of the corresponding subjects.</text>
    <sha1>42d5daee84e25d11ceb58e393d337f2d4c29ac6a</sha1>
  </revision>
</page>
<page arvcontinue="20101017125844|1559">
  <title>Backup MX</title>
  <ns>0</ns>
  <id>26</id>
  <revision>
    <id>1602</id>
    <parentid>1558</parentid>
    <timestamp>2020-10-10T09:54:50Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>Do references w/o &lt;ref&gt;, fix link for [1].</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="7510" xml:space="preserve">A '''backup MX''', also called a '''secondary MX''', is an optional server that accepts mail for the target domain on behalf of the ''primary MX''. It does not store messages in users' mailboxes, but will attempt to relay them to a primary server.

== Why have a backup MX ==
There are two main reasons why a primary MX may not be reachable: Server or network outages.

Server outages are a problem also for retrieving mail, via IMAP or POP. It may make sense to run a backup MX in case backup hosts are available for retrieving mail, in a fault-tolerant infrastructure. Minor annoyance may result from non-compliant transmitters that are configured with an unacceptably low retry interval. According to RFC 5321, ''the give-up time generally needs to be at least 4-5 days.'' A few postmasters configure much shorter intervals, perhaps because they think that delayed DSNs are difficult to understand for their users. That way, they won't be able to cope with a target host being temporarily down for a few days.

Network outages are more subtle. There was an era when backup MXes were useful to deal with networks that didn't have routes to some parts of the net. That's a pretty small niche now. However, asymmetric routing faults are still pretty common, especially in developing countries. A conservative setup may provide for a backup MX somewhere else that has a backup link to get mail to the primary when regular connectivity isn't working. An additional concern is that backbone links may go down due to [http://science.nasa.gov/headlines/y2006/10mar_stormwarning.htm solar activity], terrorism, or war. A backup MX in Australia, for example, may make a message to be timely delivered from the US to Europe even while the Atlantic link is down.

A third reason for setting up a "backup MX" is to explicitly acquire connectivity even when no outage disrupts normal operations. For example, the target host is on Mars and can be accessed, easily and normally, by other Martian hosts.  However,
	for a host on Earth, the target host will rarely be
	reachable via a normal TCP/SMTP connection and the
	intermediate MX host may have the needed delay-tolerant
	machinery installed[1]
On the Earth, a more common example is provided by (large) enterprises who  operate dedicated boundary servers as their MX platforms, and handle final delivery by an entirely different set of servers often totally invisible to the outside user.[2]

In any case, SMTP provides for a default for transferring mail from the backup MX to the target host. That is not a requirement, though. LMTP (RFC 2033), UUCP (RFC 976), or any any other mutually-acceptable transport mechanism may do.

== Why not to have a backup MX ==
With multiple connections and good hardware, it is not difficult to have 99+% uptime. Considering that performance an indicator of future results, backup MXes can be ruled out. However, the real reason for doing so is [[wp:Backscatter (e-mail)|backscatter]].

According to current standards and best practices, in order to setup a backup MX for ''example.com'', it is enough to
# configure the backup server, e.g. ''backup.example.org'', to accept mail for ''example.com'', and
# add a record in ''example.com'' DNS zone, saying that ''backup.example.org'' is an MX server with less preference (higher number) than the primary.

In principle, a client should attempt to deliver mail at the target domain's ''preferred'' (primary) server. However, spammers are exempted, and it is not easy for a secondary server to establish whether a client could have reached the primary at a given time (if the secondary can reach the primary, the primary may attempt to trace its route to the client and communicate the result back to the secondary.) A backup MX should accept mail destined to ''any'' user of the domain backed up (''example.com''), unless it has a copy of the users' database.

Currently, organizations that coordinate several servers across various networks, may internally arrange for a cache of the users database to be available at a backup MX's. Organizations whose networks would require to outsource them, while primary MXes are contracted in, cannot do that. They are better off avoiding a backup MX, because mail accepted by the backup for nonexistent users would result in backscatter. Thus, they may be in for a hard surprise in case connections worsen, e.g. because of solar flares[3].

== Alternatives and requirements ==

The [[solution proposed]] for forwarding may somewhat lend itself for also doing backup MXes. That scenario implies that a backup MX has implicit [[forwarding recipe]]s for all users to all more preferred servers in the domain being backed up. The backup server would still have to negotiate a [[forwarding agreement]] in each case where a message actually has to go through for the first time. (Existing recipes are to be searched before implicit ones.)

A cute trick to initialize the system so that it doesn't have to reply 4xx codes until agreements are finalized, which is likely to happen if the primary host is down, is to provide a list of hashed email addresses. That way, a backup MX may check that a given address actually exists, and accept it, being confident that the primary server will accept it in turn. The forwarding agreement will be negotiated when the primary (or a more preferred secondary) comes up. That circumstance more or less coincides with the moment when the cleartext address corresponding to the hashed entry becomes known at the server. Since provisions for accepting forwarding agreements from a backup MX should have been set up already at the primary's, we can regard as substantially irrelevant the short period of time while the first message for a given address remains stored in the backup MX's cache. (During that time, the server knows the email address without being bound by an agreement.)

Besides the list of hashes, the ''initialization data'', may contain regular expressions to account for subaddresses, prefixes, catch-all's, honeypots, etcetera. More meta data may be needed. Provisions to periodically refresh the initialization data are also needed. Changes in the DNS that add or remove MXes, or just change preferences, have to be dealt with.

End users should not be able to delete their forwarding agreement at a backup MX, unless they also delete their mailbox at the primary MX. Blocking such agreements, i.e. leaving an existing recipe in place while configuring it to reply ''551 User not local'', may result in some disruption and noncompliance. Such blocking may be disallowed by domain policies. At any rate, privacy concerned users will gain the ability to retrieve the effective list of servers where their email addresses are stored (a somewhat idealistic wish, until some marketing function will say otherwise.)

== See also ==
* [[boundary#Backup MXes]]
* [[forwarding recipe#Backup MXes]]
* The [http://www.imc.org/ietf-smtp/mail-archive/msg05696.html ietf-smtp thread] that inspired this page
* [[wp:MX record#The backup MX]]

== References ==

# John Klensin, [https://www.mhonarc.org/archive/html/ietf-smtp/2009-05/msg00050.html ietf-smtp mailing list], Sat, 23 May 2009 11:10:48 -0400
# Malcolm Weir, [http://www.mail-archive.com/courier-users@lists.sourceforge.net/msg35222.html courier-users], Wed, 22 Sep 2010 16:00:19 -0700
# [http://www.nasa.gov/topics/solarsystem/features/spaceweather_hazard.html NASA-Funded Study Reveals Hazards of Severe Space Weather] 1 May 2009
&lt;references /&gt;</text>
    <sha1>85e39737e32256299753a0274de58d9c43966bed</sha1>
  </revision>
  <revision>
    <id>1603</id>
    <parentid>1602</parentid>
    <timestamp>2020-12-21T11:38:48Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Why have a backup MX */ Add from mailop thread December 2020</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="9191" xml:space="preserve">A '''backup MX''', also called a '''secondary MX''', is an optional server that accepts mail for the target domain on behalf of the ''primary MX''. It does not store messages in users' mailboxes, but will attempt to relay them to a primary server.

== Why have a backup MX ==
There are two main reasons why a primary MX may not be reachable: Server or network outages.

Server outages are a problem also for retrieving mail, via IMAP or POP. It may make sense to run a backup MX in case backup hosts are available for retrieving mail, in a fault-tolerant infrastructure. Minor annoyance may result from non-compliant transmitters that are configured with an unacceptably low retry interval. According to RFC 5321, ''the give-up time generally needs to be at least 4-5 days.'' A few postmasters configure much shorter intervals, perhaps because they think that delayed DSNs are difficult to understand for their users. That way, they won't be able to cope with a target host being temporarily down for a few days.

Network outages are more subtle. There was an era when backup MXes were useful to deal with networks that didn't have routes to some parts of the net. That's a pretty small niche now. However, asymmetric routing faults are still pretty common, especially in developing countries. A conservative setup may provide for a backup MX somewhere else that has a backup link to get mail to the primary when regular connectivity isn't working. An additional concern is that backbone links may go down due to [http://science.nasa.gov/headlines/y2006/10mar_stormwarning.htm solar activity], terrorism, or war. A backup MX in Australia, for example, may make a message to be timely delivered from the US to Europe even while the Atlantic link is down.

A third reason for setting up a "backup MX" is to explicitly acquire connectivity even when no outage disrupts normal operations. For example, the target host is on Mars and can be accessed, easily and normally, by other Martian hosts.  However,
	for a host on Earth, the target host will rarely be
	reachable via a normal TCP/SMTP connection and the
	intermediate MX host may have the needed delay-tolerant
	machinery installed[1]
On the Earth, a more common example is provided by (large) enterprises who  operate dedicated boundary servers as their MX platforms, and handle final delivery by an entirely different set of servers often totally invisible to the outside user.[2]

In any case, SMTP provides for a default for transferring mail from the backup MX to the target host. That is not a requirement, though. LMTP (RFC 2033), UUCP (RFC 976), or any any other mutually-acceptable transport mechanism may do.

=== Google ===

Digging for gmail.com's MXes brings about quite some:
    ;; ANSWER SECTION:
    gmail.com.		473	IN	MX	30 alt3.gmail-smtp-in.l.google.com.
    gmail.com.		473	IN	MX	5 gmail-smtp-in.l.google.com.
    gmail.com.		473	IN	MX	10 alt1.gmail-smtp-in.l.google.com.
    gmail.com.		473	IN	MX	40 alt4.gmail-smtp-in.l.google.com.
    gmail.com.		473	IN	MX	20 alt2.gmail-smtp-in.l.google.com.

They do so for two reasons: most mailers will retry immediately on some connection errors (even as late as starttls or helo) but only if you have "more" hosts/IPs for them to try.  With load balancers, there's no other way to tell remote servers to try again quickly.

The other reason is that they are able to vend an IP to DNS requests based on load/availability and closeness to the requester.  Their alt addresses vend other data centers down the list, which helps move the traffic in the first minutes of unavailability before the automated systems catch up and the DNS ttl expires.

Ah, and they also used multiple MXes to roll out changes.  For example, when they rolled out ipv6 addresses, they added it on a higher number MX first.

=== [https://wiki.junkemailfilter.com/index.php/Project_Tar Project Tar] and [http://nolisting.org/ nolisting] ===

The approach preferred by Grant Taylor:

# Point the primary MX at a server with nothing listening.  It will send TCP Resets —known as "No Listing", a variant of "Grey Listing".—  I have yet to see any negative side effects with this.
# Point the secondary MX at your main mail server —Business as usual.
# Optionally - Point the tertiary at your backup mail server.
# Point the last MX at something like Project Tar.

== Why not to have a backup MX ==
With multiple connections and good hardware, it is not difficult to have 99+% uptime. Considering that performance an indicator of future results, backup MXes can be ruled out. However, the real reason for doing so is [[wp:Backscatter (e-mail)|backscatter]].

According to current standards and best practices, in order to setup a backup MX for ''example.com'', it is enough to
# configure the backup server, e.g. ''backup.example.org'', to accept mail for ''example.com'', and
# add a record in ''example.com'' DNS zone, saying that ''backup.example.org'' is an MX server with less preference (higher number) than the primary.

In principle, a client should attempt to deliver mail at the target domain's ''preferred'' (primary) server. However, spammers are exempted, and it is not easy for a secondary server to establish whether a client could have reached the primary at a given time (if the secondary can reach the primary, the primary may attempt to trace its route to the client and communicate the result back to the secondary.) A backup MX should accept mail destined to ''any'' user of the domain backed up (''example.com''), unless it has a copy of the users' database.

Currently, organizations that coordinate several servers across various networks, may internally arrange for a cache of the users database to be available at a backup MX's. Organizations whose networks would require to outsource them, while primary MXes are contracted in, cannot do that. They are better off avoiding a backup MX, because mail accepted by the backup for nonexistent users would result in backscatter. Thus, they may be in for a hard surprise in case connections worsen, e.g. because of solar flares[3].

== Alternatives and requirements ==

The [[solution proposed]] for forwarding may somewhat lend itself for also doing backup MXes. That scenario implies that a backup MX has implicit [[forwarding recipe]]s for all users to all more preferred servers in the domain being backed up. The backup server would still have to negotiate a [[forwarding agreement]] in each case where a message actually has to go through for the first time. (Existing recipes are to be searched before implicit ones.)

A cute trick to initialize the system so that it doesn't have to reply 4xx codes until agreements are finalized, which is likely to happen if the primary host is down, is to provide a list of hashed email addresses. That way, a backup MX may check that a given address actually exists, and accept it, being confident that the primary server will accept it in turn. The forwarding agreement will be negotiated when the primary (or a more preferred secondary) comes up. That circumstance more or less coincides with the moment when the cleartext address corresponding to the hashed entry becomes known at the server. Since provisions for accepting forwarding agreements from a backup MX should have been set up already at the primary's, we can regard as substantially irrelevant the short period of time while the first message for a given address remains stored in the backup MX's cache. (During that time, the server knows the email address without being bound by an agreement.)

Besides the list of hashes, the ''initialization data'', may contain regular expressions to account for subaddresses, prefixes, catch-all's, honeypots, etcetera. More meta data may be needed. Provisions to periodically refresh the initialization data are also needed. Changes in the DNS that add or remove MXes, or just change preferences, have to be dealt with.

End users should not be able to delete their forwarding agreement at a backup MX, unless they also delete their mailbox at the primary MX. Blocking such agreements, i.e. leaving an existing recipe in place while configuring it to reply ''551 User not local'', may result in some disruption and noncompliance. Such blocking may be disallowed by domain policies. At any rate, privacy concerned users will gain the ability to retrieve the effective list of servers where their email addresses are stored (a somewhat idealistic wish, until some marketing function will say otherwise.)

== See also ==
* [[boundary#Backup MXes]]
* [[forwarding recipe#Backup MXes]]
* The [http://www.imc.org/ietf-smtp/mail-archive/msg05696.html ietf-smtp thread] that inspired this page
* [[wp:MX record#The backup MX]]

== References ==

# John Klensin, [https://www.mhonarc.org/archive/html/ietf-smtp/2009-05/msg00050.html ietf-smtp mailing list], Sat, 23 May 2009 11:10:48 -0400
# Malcolm Weir, [http://www.mail-archive.com/courier-users@lists.sourceforge.net/msg35222.html courier-users], Wed, 22 Sep 2010 16:00:19 -0700
# [http://www.nasa.gov/topics/solarsystem/features/spaceweather_hazard.html NASA-Funded Study Reveals Hazards of Severe Space Weather] 1 May 2009
&lt;references /&gt;</text>
    <sha1>401f1136b2121d7ef2ac69f804d439d2f5f54394</sha1>
  </revision>
  <revision>
    <id>1604</id>
    <parentid>1603</parentid>
    <timestamp>2020-12-21T16:37:38Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Project Tar and nolisting */</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="9293" xml:space="preserve">A '''backup MX''', also called a '''secondary MX''', is an optional server that accepts mail for the target domain on behalf of the ''primary MX''. It does not store messages in users' mailboxes, but will attempt to relay them to a primary server.

== Why have a backup MX ==
There are two main reasons why a primary MX may not be reachable: Server or network outages.

Server outages are a problem also for retrieving mail, via IMAP or POP. It may make sense to run a backup MX in case backup hosts are available for retrieving mail, in a fault-tolerant infrastructure. Minor annoyance may result from non-compliant transmitters that are configured with an unacceptably low retry interval. According to RFC 5321, ''the give-up time generally needs to be at least 4-5 days.'' A few postmasters configure much shorter intervals, perhaps because they think that delayed DSNs are difficult to understand for their users. That way, they won't be able to cope with a target host being temporarily down for a few days.

Network outages are more subtle. There was an era when backup MXes were useful to deal with networks that didn't have routes to some parts of the net. That's a pretty small niche now. However, asymmetric routing faults are still pretty common, especially in developing countries. A conservative setup may provide for a backup MX somewhere else that has a backup link to get mail to the primary when regular connectivity isn't working. An additional concern is that backbone links may go down due to [http://science.nasa.gov/headlines/y2006/10mar_stormwarning.htm solar activity], terrorism, or war. A backup MX in Australia, for example, may make a message to be timely delivered from the US to Europe even while the Atlantic link is down.

A third reason for setting up a "backup MX" is to explicitly acquire connectivity even when no outage disrupts normal operations. For example, the target host is on Mars and can be accessed, easily and normally, by other Martian hosts.  However,
	for a host on Earth, the target host will rarely be
	reachable via a normal TCP/SMTP connection and the
	intermediate MX host may have the needed delay-tolerant
	machinery installed[1]
On the Earth, a more common example is provided by (large) enterprises who  operate dedicated boundary servers as their MX platforms, and handle final delivery by an entirely different set of servers often totally invisible to the outside user.[2]

In any case, SMTP provides for a default for transferring mail from the backup MX to the target host. That is not a requirement, though. LMTP (RFC 2033), UUCP (RFC 976), or any any other mutually-acceptable transport mechanism may do.

=== Google ===

Digging for gmail.com's MXes brings about quite some:
    ;; ANSWER SECTION:
    gmail.com.		473	IN	MX	30 alt3.gmail-smtp-in.l.google.com.
    gmail.com.		473	IN	MX	5 gmail-smtp-in.l.google.com.
    gmail.com.		473	IN	MX	10 alt1.gmail-smtp-in.l.google.com.
    gmail.com.		473	IN	MX	40 alt4.gmail-smtp-in.l.google.com.
    gmail.com.		473	IN	MX	20 alt2.gmail-smtp-in.l.google.com.

They do so for two reasons: most mailers will retry immediately on some connection errors (even as late as starttls or helo) but only if you have "more" hosts/IPs for them to try.  With load balancers, there's no other way to tell remote servers to try again quickly.

The other reason is that they are able to vend an IP to DNS requests based on load/availability and closeness to the requester.  Their alt addresses vend other data centers down the list, which helps move the traffic in the first minutes of unavailability before the automated systems catch up and the DNS ttl expires.

Ah, and they also used multiple MXes to roll out changes.  For example, when they rolled out ipv6 addresses, they added it on a higher number MX first.

=== [https://wiki.junkemailfilter.com/index.php/Project_Tar Project Tar] and [http://nolisting.org/ nolisting] ===

The approach preferred by Grant Taylor:

# Point the primary MX at a server with nothing listening.  It will send TCP Resets —known as "No Listing", a variant of "Grey Listing".—  I have yet to see any negative side effects with this.
# Point the secondary MX at your main mail server —Business as usual.
# Optionally - Point the tertiary at your backup mail server.
# Point the last MX at something like Project Tar.

Another participant report getting some hours delay with nolisting, and prefers (smart) greylisting.

== Why not to have a backup MX ==
With multiple connections and good hardware, it is not difficult to have 99+% uptime. Considering that performance an indicator of future results, backup MXes can be ruled out. However, the real reason for doing so is [[wp:Backscatter (e-mail)|backscatter]].

According to current standards and best practices, in order to setup a backup MX for ''example.com'', it is enough to
# configure the backup server, e.g. ''backup.example.org'', to accept mail for ''example.com'', and
# add a record in ''example.com'' DNS zone, saying that ''backup.example.org'' is an MX server with less preference (higher number) than the primary.

In principle, a client should attempt to deliver mail at the target domain's ''preferred'' (primary) server. However, spammers are exempted, and it is not easy for a secondary server to establish whether a client could have reached the primary at a given time (if the secondary can reach the primary, the primary may attempt to trace its route to the client and communicate the result back to the secondary.) A backup MX should accept mail destined to ''any'' user of the domain backed up (''example.com''), unless it has a copy of the users' database.

Currently, organizations that coordinate several servers across various networks, may internally arrange for a cache of the users database to be available at a backup MX's. Organizations whose networks would require to outsource them, while primary MXes are contracted in, cannot do that. They are better off avoiding a backup MX, because mail accepted by the backup for nonexistent users would result in backscatter. Thus, they may be in for a hard surprise in case connections worsen, e.g. because of solar flares[3].

== Alternatives and requirements ==

The [[solution proposed]] for forwarding may somewhat lend itself for also doing backup MXes. That scenario implies that a backup MX has implicit [[forwarding recipe]]s for all users to all more preferred servers in the domain being backed up. The backup server would still have to negotiate a [[forwarding agreement]] in each case where a message actually has to go through for the first time. (Existing recipes are to be searched before implicit ones.)

A cute trick to initialize the system so that it doesn't have to reply 4xx codes until agreements are finalized, which is likely to happen if the primary host is down, is to provide a list of hashed email addresses. That way, a backup MX may check that a given address actually exists, and accept it, being confident that the primary server will accept it in turn. The forwarding agreement will be negotiated when the primary (or a more preferred secondary) comes up. That circumstance more or less coincides with the moment when the cleartext address corresponding to the hashed entry becomes known at the server. Since provisions for accepting forwarding agreements from a backup MX should have been set up already at the primary's, we can regard as substantially irrelevant the short period of time while the first message for a given address remains stored in the backup MX's cache. (During that time, the server knows the email address without being bound by an agreement.)

Besides the list of hashes, the ''initialization data'', may contain regular expressions to account for subaddresses, prefixes, catch-all's, honeypots, etcetera. More meta data may be needed. Provisions to periodically refresh the initialization data are also needed. Changes in the DNS that add or remove MXes, or just change preferences, have to be dealt with.

End users should not be able to delete their forwarding agreement at a backup MX, unless they also delete their mailbox at the primary MX. Blocking such agreements, i.e. leaving an existing recipe in place while configuring it to reply ''551 User not local'', may result in some disruption and noncompliance. Such blocking may be disallowed by domain policies. At any rate, privacy concerned users will gain the ability to retrieve the effective list of servers where their email addresses are stored (a somewhat idealistic wish, until some marketing function will say otherwise.)

== See also ==
* [[boundary#Backup MXes]]
* [[forwarding recipe#Backup MXes]]
* The [http://www.imc.org/ietf-smtp/mail-archive/msg05696.html ietf-smtp thread] that inspired this page
* [[wp:MX record#The backup MX]]

== References ==

# John Klensin, [https://www.mhonarc.org/archive/html/ietf-smtp/2009-05/msg00050.html ietf-smtp mailing list], Sat, 23 May 2009 11:10:48 -0400
# Malcolm Weir, [http://www.mail-archive.com/courier-users@lists.sourceforge.net/msg35222.html courier-users], Wed, 22 Sep 2010 16:00:19 -0700
# [http://www.nasa.gov/topics/solarsystem/features/spaceweather_hazard.html NASA-Funded Study Reveals Hazards of Severe Space Weather] 1 May 2009
&lt;references /&gt;</text>
    <sha1>ec7c6c63da6ca035fc510cfcbb76e666b8f9e7fc</sha1>
  </revision>
</page>
<page arvcontinue="20231013085637|1610">
  <title>Main Page</title>
  <ns>0</ns>
  <id>1</id>
  <revision>
    <id>1610</id>
    <parentid>1609</parentid>
    <timestamp>2023-10-13T08:56:37Z</timestamp>
    <contributor>
      <username>Ale</username>
      <id>1</id>
    </contributor>
    <comment>/* Legal conundrum */ link https://www.eff.org/deeplinks/2023/08/californias-delete-act-protects-us-data-brokers</comment>
    <model>wikitext</model>
    <format>text/x-wiki</format>
    <text bytes="14221" xml:space="preserve">Email addresses are personal data notoriously being abused.  There is an ongoing quest for anti-spam techniques.  However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.

== Rationale ==
Both personal messaging and direct marketing would benefit from an unpolluted communication environment.  Pollution results from insanely conceiving sales like a prey-predator relationship with customers.  Production and distribution of goods and services should rather be a symbiotic relationship.  The minority working against that ought to be pushed off.  A ''responsible marketing'' is the precondition for commercial strength in the [[wp:Information Age]].

== The problem ==
[[File:List.png|200px|thumb|left|Sending messages to a list is one of the [[standard behavior]]s.]] There is an outstanding feature of sending bulk messages that characterizes email: the destination addresses can be held on a ''list exploder''.  Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a ''pseudo-mailbox'' that the list exploder uses to select addresses from a local database.  Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system.

[[wp:Email Authentication]] is typically baffled by indirect mail flows.  [[wp:Sender Policy Framework|SPF]] breaks forwarding by design.  [[wp:DomainKeys Identified Mail|DKIM]] should withstand forwarding.  However, occasional alterations or deliberate, legitimate additions break signatures as well.  This state of affairs hinders the possibility to use domain authentication as a means to control email abuse.  If it were not for forwarding, it would be possible to build reliable reputation systems.  That way, authors would have to be responsible for what they send.

A possible mitigation is to pair the email addresses stored on a list exploder with tags stored at the corresponding receivers, so that the latter can categorize indirect mail flows and allow their users to control them.  This idea is drafted in [https://datatracker.ietf.org/doc/html/draft-vesely-fix-forwarding Agreements To Fix Forwarding]

== Legal conundrum ==
In most countries, storing personal data on a server should be controlled by law.  In Europe, in particular, this is never done in compliance with the letter of [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML Directive 95/46/EC].  Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued. '''2023 update:''' [https://www.eff.org/deeplinks/2023/08/californias-delete-act-protects-us-data-brokers California's DELETE Act Protects Us From Data Brokers].

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time.  Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing.  Such ambiguous feeling sorts little practical effects, if any.  In particular:
* while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
* mailing lists have no means to prove subscriptions,
* newsletters don't allow recipients to directly control the forwarding mechanism,
* illegal disclosure of email addresses cannot be detected,
* responsibility for injecting spam remains ambiguous,
* bounces from forwarders may reveal recipients' identities thereby betraying any anonymity concern that forwarding might have implied.

One of the downsides of [[wp:Data Protection Directive]] is the work required for collecting subjects' consent.  For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures.  On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

There is an EU regulation, [[wp:eIDAS]], a standard developed for transactions in the EU single market.  It can be considered a sort of S/MIME extension; that is, it features centralized key management -the main difference w.r.t. the PGP suite.  That way, data subject's consent could by acquired by means of a ''trust service provider'' according to regulation.  A statement like this would be consistent with law-regulated privacy protection.

== Triple Opt-In ==

[[wp:Opt in email]] is the mail that users receive because they subscribed.

''Double opt-in'' is a technique to confirm subscriptions.  The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process.  That way the operator knows that email addresses are correct and belongs to the subscribers.  List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions.  However, malicious operators can easily build fake opt-in evidence.

''Triple opt-in'' would be a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription.  Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data.  This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.

===Criticism===
The main reason why that kind of authentication won't come is that it implies a trust between users and their mailbox providers.  Such trust may seem to be taken for granted, considering, for example, that forgotten passwords are reset through email.  A person's email address has become an identity token.  Yet, there are users who hardly cope with having to entrust their communications to a third party suspected of sniffing it, profiling and reselling private data, and worse.  Things would be different if the mailbox provider were the server of a household, of a company, a club, or similar associations.  In fact, the 'domain-part' of an address used to characterize people.  Nowadays, everyone has 'gmail'.  There are two reasons for this state of affairs.  One is that running a mail server is not so straightforward.  The other one is that server connections cost much more than residential ones.  Having to put the server at the mercy of an external admin doesn't seem to be much different than letting the external admin manage the mail directly, as far as privacy is concerned.

A reason to avoid the term ''triple opt-in'' altogether is that it is being used with a different (marketing) meaning, see e.g. [http://www.mmaglobal.com/wiki/triple-opt here].

An additional weakness is that a user's mail server can just be grateful for the information supplied, and decline to send a proper acknowledge to the wannabe sender.  Since the sender is doing this in order to have such legal proof of its conduct, lazy mailbox provider behavior can hamper a naive implementation.

Let me name this [[Water tight opt-in]], following David Hofstee.

== A consent-exchange Internet protocol for email users ==
A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool ''could'' gain interest if it also stipulates means to obtain proofs of consent with legal standing.  It is necessary to involve the [[wp:Article 29 Working Party]] for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller.  The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details.  It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

* an automatically updated list of subscriptions and redirections,
* actual possibility to erase or rectify the data in each entry,
* easy verification of legitimate behavior,
* catching some illegitimate disclosures of addresses,
* better anti-spam filtering by whitelisting legitimate messages, and
* enabling automation of abuse reporting.

=== Update 2018 ===
The new [http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679 REGULATION 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL] of 27 April 2016, article 68, states (my enhancing):
&lt;blockquote&gt;
To further strengthen the control over his or her own data, where the processing of personal data is carried out by automated means, the data subject should also be allowed to receive personal data concerning him or her which he or she has provided to a controller in a structured, commonly used, machine-readable and interoperable format, and to transmit it to another controller. '''Data controllers should be encouraged to develop interoperable formats that enable data portability.''' That right should apply where the data subject provided the personal data on the basis of his or her consent or the processing is necessary for the performance of a contract. It should not apply where processing is based on a legal ground other than consent or contract. By its very nature, that right should not be exercised against controllers processing personal data in the exercise of their public duties. It should therefore not apply where the processing of the personal data is necessary for compliance with a legal obligation to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of an official authority vested in the controller. The data subject's right to transmit or receive personal data concerning him or her should not create an obligation for the controllers to adopt or maintain processing systems which are technically compatible. Where, in a certain set of personal data, more than one data subject is concerned, the right to receive the personal data should be without prejudice to the rights and freedoms of other data subjects in accordance with this Regulation. Furthermore, that right should not prejudice the right of the data subject to obtain the erasure of personal data and the limitations of that right as set out in this Regulation and should, in particular, not imply the erasure of personal data concerning the data subject which have been provided by him or her for the performance of a contract to the extent that and for as long as the personal data are necessary for the performance of that contract. Where technically feasible, the data subject should have the right to have the personal data transmitted directly from one controller to another.
&lt;/blockquote&gt;

Besides all the limitations intended to safeguard data controllers, it clearly calls for such a standard.

=== Update 2023 ===
After more thinking, catching both user confirmation to the mailing list and user's mailbox provider consent to pass the mail flow in a single gesture is too much.  The protocol shall provided for both points to be done asynchronously.

== DNS declaration of mailing list ==
Yet another idea is to use DNS RRs to declare that a given email address is a mailing list (suggested by John Levine [http://www.ietf.org/mail-archive/web/ietf-822/current/msg06714.html here]).  It is exemplified as

  &amp;lt;hash of ietf-822&amp;gt;._mayresign.ietf.org TXT "v=MR1; d=ietf.org"

That says the ietf-822 at ietf.org list is signed with d=ietf.org.  If a domain contains only mailing lists, you can use a wildcard

  *._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"

A submission server can then derive that one of its users is a subscriber of a list declared that way.

== Anti-spam effect==
The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff.  The ''triple opt-in'' protocol outlined here can only control legal spam.  However, it is not straightforward to tell legal and illegal spam apart, currently.  A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.

&lt;!-- old stuff
Forwarding is an agreement between two entities, the owners of the relevant mailboxes. The [[solution proposed]] is designed so as to reflect this property; in particular, it provides for a ''standard way'' for recipients to learn that their mailbox address has been configured as the target of a forwarding recipe.

The ''opt-in'' and ''opt-out'' methods have been discussed at length, and are ratified in a number of [[privacy laws]]. The FixForwarding solution provides for an implementation for some of those recommendations, not otherwise formalized by the [[wp:IETF|IETF]].

Are we serious about using email?
--&gt;

== Papers ==
A nice taxonomy of email forwarding methods and weaknesses thereof, as of 2023, is given by [https://arxiv.org/search/cs?searchtype=author&amp;query=Liu%2C+E Enze Liu] et al. [https://arxiv.org/abs/2302.07287 Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy].</text>
    <sha1>3df1c4ea713be5fccd24a3cd82664110c96397c9</sha1>
  </revision>
</page>
</mediawiki>